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Specification of 3 Software Architecture for Capability and 
Quality-of -Service Negotiations and Session Establishment for 
Distributed Multimedia Applications 

5 

The underlying invention generally relates to the field of 
distributed mobile computing in a mobile wireless networking 
environment with distributed multimedia applications and sys- * 
terns. More specifically, it is directed to the field of qual- 

10 ity negotiation and session establishment for adaptive 

real-time streaming services running on fixed and mobile de- 
vices which support different access technologies in dynamic 
wireless Internet Protocol (IP) networks , thereby including 
research and development issues which are especially related 

15 to multimedia middleware and resource reservation mechanisms* 

A problem that distributed systems will most likely face is 
how to cope with limited resources at the end systems and iii 
the network, and unstable environment conditions. Mobile us - 

20 ers are in fact expected to incur more frequently on the un-. 
fortunate case of having their QoS Contracts being no longer 1 
supported by the network infrastructure, due to various rea-. 
sons like wireless link quality degradations, horizontal : 
and/or vertical handovers, limited amount of mobile terminal 

25 resources, etc., which shall be referred to as „QoS viola- < 
tions". By assuming proper resource overprovision in the 
backbone, it can be expected that QoS violations will most 
likely originate due to handovers or within the access net- ■ 
work, especially in the radio part thereof. 

30 

Furthermore, mobile multimedia applications dealing with mul- 
tiple media streams of information being simultaneously ex- 
changed with a multiplicity of peers require an effective and 
efficient way of negotiating capabilities and handling QoS 
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requirements, especially in view of the aforementioned unsta- 
ble environment conditions . 

A possible way of coping with unstable environment conditions 
5 is to enable the mobile users' applications to efficiently 
and timely react to QoS violations. Peers can in fact negoti- 
ate off-line various alternative QoS Contracts at different 
levels of abstraction, so that at the time when a connection 
is established and whenever QoS violations occur, agreements 
10 on how to most effectively adapt to the mutated conditions 
"can" timely be "accomplished among the peers. 

BRIEF DESCRIPTION OF THE PRESENT STATE OF THE ART 

15 In the European patent application EP 01 122 366.6, the End- 
to-End Negotiation Protocol (E2ENP) has already been intro- 
duced and described in detail. As the present invention de- 
velops further the ideas described in this European patent 
application, its disclosure is hereby incorporated by refer- 

20 ence. 

The following table gives a brief overview of recently pub- 
lished articles which describe the concept of QoS and capa- 
bility negotiation protocols (in alphabetical order) : 



Abbr. 


Publication ' 


[Ber] 


T. Berners-Lee et al.: „Uniform Resource Identi~ 
fiers (URI) : Generic Syntax", Networking Working 
Group, Standards Track RFC 2396. 


[Bosl] 


L. Bos et al.: „A Framework for End-to-End User — 
Perceived Quality of Service Negotiation", IETF 
Internet Draft, work in progress, <draft-bos- 
mmusic-sdpqos-framework-OO.txt>. It describes a 
process for negotiating QoS with SIP and SDP be- 
tween two peers. However, it does not describe 
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Abbr. 


Publication 




any architecture for the entity using this proc- 
ess . 


[Bos2] 


L. Bos et al.: „SDPng Extensions for Quality-of- 
Service Negotiation", IETF Internet Draft, work 
in n*rorrTe»c;s . <draf fc— bos- mmu s ic—s doner— cros— 
OO.txt>. It describes a process for negotiating 
QoS with SIP and SDP between two peers. However, 
it does not describe any software architecture 
fnr t"hi» f*nt"i1"v usincr this Dronpss . 


[BRAIN] 


^Concepts for Service Adaptation, Scalability 
and QoS Handling on Mobility-Enabled Networks", 
IST-1999-10050 BRAN Deliverable 1.2 
(http://www.ist-brain.org/). 




7\ Pfacel or o+* ^ 1 • RRFMTA — ^nnDnri* i "nrr Mrih"i 1 i "hv 
j-\ » JXaoolcl fci L. clx . • ^dimjin lxi, u uppui. i — Liiy nujj j_ j — l y 

and Quality of Service for Adaptable Multimedia 
Communication", in: Proceedings of the 1ST Mo- 
bile Communications Summit 2000, Galway, Ire- 
land, October 2000, pp. 403-408. 


[Carnl] 


G. Camarillo, W. Marshall, J. Rosenberg: 
^Integration of Resource Management and SIP XX , 
IETF Internet Draft , work in progress, <draft- 
ietf-sip-manyfolks-resource-07 . txt>. It develops 
■hh p> Tf^cni n rprapnts of an ..Of f er/Answer Model" 
based on SDP, also in the sense of reservation. 
However, it does not describe any software ar- 
chitecture for the entity performing such spe- 
cific negotiations. 


[Cam2] 


G. Camarillo et al . : „Grouping of Media Lines in 
SDP" (IETF Internet Draft, work in progress, 
<draft-ietf-mmusic-f id-04 . txt>) . 


[Gam] 


E. Gamma et al . : „Design Patterns - Elements of 
Reusable Object-Oriented Software", Addison- 
Wesley, Reading-Massachusetts (USA), 1994. 
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lAbbr. 


| Publication ' ■ 


[Gu] 


IX. Gu, K. Nahrstedt et al.: „An XML-based Qual- 
ity-of-Service-Enabling Language for the Web", 
Project Report of the National Science Founda- 
tion, 2001. 


[Gue] 


1 T . GUenkOVV— LUV. A TCacd q-v- r nj _i :r — — 

uu ^> riassier, j. Eisl, D. Man- 
dator ^Efficient End-to-End QoS Signaling - con- 
i ^ j: cauuj - eb / xiLii! internet Draft, work 

in progress, <draf t-guenkova-mmusic-e2enp-sdpng- 
00.txt>. 


[Klyl] : 


G. Klyne: „A Syntax for Describing Media Feature 

SetS M , IETF RFP 2^^^ 


[Kly2] 


IG. Klyne: identifying Composite Media Fea- 
tures", IETF RFC 2938. It describes an optimiza- 
tion for the algorithm disclosed in [Klyl] by 

introducincr H = +- => Vian^i « ~ i . . 

j.xxi-j.<_>u.ui — my uata nanaies and hashing. 


[Kutl] 


D. Kutscher et al.: Requirements for Session 
Description and Capability Negotiation" (IETF 

Internet Draft - unrv -j r» nv<\/.«>>. -> i — , 
i-siuo. uiai i-/ wots m progress, <draft— 

kutscher-mmusic-sdpng-req-01.txt>) . 


[Kut2] . 1 
[Manl] t 


D. Kutscher et al.: „Session Description and Ca-~ 
pability Negotiation", IETF Internet Draft, work 
in progress, <draf t-ietf-mmusic-sdpng-05 . txt>. 




D. Mandate A. Kassler, T. Robles, G. Neureiter: 
„Concepts for Service Adaptation, Scalability 
and QoS Concepts on Mobility-Enabled Networks" 

(1ST Global Summit- onrn ^ t « 

v OXUiJai oununiL zuv±, Barcelona, September 

2001, pp. 285-293). This article describes the 
core concepts of the End-to-End Negotiation Pro- 
tocol (E2ENP) . A similar paper has been pre- 
sented at PIMRC 2001 in San Diego, October 2001. 


[Man2] | 

i 1 


D. Mandate, A. Kassler, T. Robles and G. Neure- 
iter: „Handling End-to-End QoS in Mobile Hetero- 
geneous Networking Environments" (PIMRC 2001, 
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Abbr. 


Publication 




San Diego, 30/9/2001. to 3/10/2001, pp. C-49 to 
C-54) 


[ReqSpec] 


„End-to-End Negotiation Protocol", IST-2000- 
28584/SO/WPl/PI/l/003/al, MIND Internal Contri- 
bution to WP1, Activity 1.3, Work Item 2. 


[Rosl] 


J. Rosenberg, H. Schulzrinne et al.: „SIP: Ses- 
sion Initiation Protocol", IETF Standards Track, 
Network Working Group, RFC 3261 This Hornmonf 
describes the Session Initiation Protocol (SIP) , 
which is an application-layer control (signal- 
ing) protocol for creating, modifying and ter- 
minating sessions with one or more participants* 


[Ros2] 


J. Rosenberg, H. Schulzrinne: „An Offer/Answer 
Model with SDP", IETF Internet Draft, work in 
progress, <draf t-ietf-mmusic-sdp-of f er-answer- 
02.txt>. This document defines a mechanism by 
which two entities can make use of SDP to pro- 
vide a common view of a multimedia session be- 
tween them. 



[Caml] presents a multi-phase call-setup mechanism that makes 
network QoS and security establishment a precondition to ses- 
sions initiated by the Session Initiation Protocol (SIP) and 
described by the Session Description Protocol (SDP) . Network 
resources are reserved before the session is started, thereby 
using existing network resource reservation mechanisms (e.g. 
RSVP) . 



[Klyl] presents a format to express media feature sets that 
represent media handling capabilities. In addition, an algo- 
rithm is provided that matches the feature sets. It might be 
used to determine if the capabilities of a sender and re- 
ceiver are compatible. In addition, in [Kly2] an abbreviated 
format for composite media feature sets that use a hash of 
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the feature representation to describe the composite is dis- 
closed. 

In [Ros2], a complete model for a one-to-one capabilities ne- 
5 gotiation with SDP is described. However, this model suffers 
from problems caused by the definition of mutually referred 
information and information on grouping media streams due to 
the flat hierarchy structure of the SDP. 

10 [Kutl] describes a set of requirements relevant for a frame- 
work for a session description' and an* end-point capability 
negotiation in multi-party multimedia conferencing scenarios. 
Depending on user preferences, system capabilities or other 
constraints, different configurations can be chosen for the 

15 conference. Thereby, the need for a negotiation process. among 
the peers is identified, but not described in order to deter- 
mine a common set of potential configurations and select one 
of the common configurations to be used for information ex- 
change. This capability negotiation is used to get a valid 

20 session description, compatible with the end system capabili- 
ties and user preferences of the potential participants. Dif- 
ferent negotiation policies may be used to reflect different 
conference types. They also identify the need for network re- 
source reservation coupled with session setup. Finally, a 

25 proposal is drafted for describing capabilities and providing 
the negotiation language, but not a protocol. Thereby, the. 
solution proposed in [Kutl] does neither consider the nego- 
tiation protocol for determining a common set of QoS configu- 
ration nor integrate local, peer and network resource reser- 

30 vation. 

The most recent version of this IETF draft, in the following 
referred to as [Kut2], provides a detailed XML Schema speci- 
fication and a prototype of the Audio Codec and Real-Time 
35 Protocol (RTP) Profiles. 
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In [Bosl], an end-to-end user-perceived QoS negotiation is 
described, with the presumption that some middleware and 
services may strongly be involved in the final decision about 
the negotiated QoS- information of the end peers- The decision 
as described may be taken over some standard ^contract, 
types". Although it is mentioned that the signaling and the 
data path may go different ways through the network, it is 
suggested that some middleware on the way of the negotiation 
path may influence the negotiation though in general having 
nothing to do with the data paths. In case. this protocol 
model is deployed, the network is not transparent. The nego- 
tiation process according to [Bosl] is performed at one shot 
interleaving also with some non-QoS information (e.g. secu- 
15 rity, network admittance, etc.) without considering protocol 
modularity and information consistency with respect to QoS. 
With the model of [Bosl], it is only possible to use a push 
mode for the negotiation, which may be restrictive for some 
applications and services. The adaptation paths are only de- 
20 grading and fixed. 

In the articles [Manl], [Man2], and [Cam2], the possibility 
of grouping media streams is discussed. However, the authors 
do not consider criteria for the grouping, the possibility of 
25 recursive group building (a group of many groups), and the 
treatment of real, pseudo-real and non-real-time information 
media streams that also may be grouped. Besides, [Manl] and 
[Man2] define negotiation steps that may or may not run at 
one shot but not during independent negotiation phases. For 
30 this reason, they do not meet the requirements for the con- 
sistency of the negotiated QoS information during a negotia- 
tion phase and after it. Thereby, in [Manl] the core concepts 
of the E2ENP are disclosed. The treatment of colliding ^Econ- 
omy Principle" applications is also not considered. Moreover, 
35 [Manl] and [Man2] describe the possibility of setting and 
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managing adaptation paths for the QoS adaptation, which is 
controlled by a third party component - the QoS Broker. How- 
ever, the authors do not consider any possibility for the end 
parties to perform and control the negotiations on their own. 

PROBLEMS TO BE SOLVED BY THE INVENTION 

Nowadays, adaptive applications and/or middleware (e.g. QoS 
Brokers) do not comprise any component which is capable of 
handling QoS pre-negotiation, QoS negotiation and/or QoS re- 
negotiation, resource reservation and/or release coordination 
offering a technology-independent Application Programming In- 
terface (API), which masks the type of signaling protocols 
used for implementing those mechanisms. Instead, adaptive 
multi-stream multimedia applications and/or middleware have 
directly to be coded against protocols like H.323, the Ses- 
sion Initiation Protocol (SIP) and/or the Session Description 
Protocol (SDP, in future SDPng as described in [Kut2] ) . Fur- 
thermore, said SIP- and/or SDP-based applications or middle- 
ware directly perform a parsing of the SDP data and have to 
infer the actions to .be taken by examining changes on the. SDP 
data from previously exchanged versions thereof. 

Another problem is that adaptive applications and/or middle- 
ware (e.g. QoS Brokers) are not able to express the informa- 
tion to be negotiated (e.g. capabilities, application-level 
QoS Contracts, network- level QoS Contracts, stream-level ad- 
aptation paths, and stream-group- level adaptation paths) in 
an interchangeable format, it is required that heterogeneous 
applications and/or middleware can easily agree on a refer- 
ence model, which said applications and/or said middleware 
can then use for dynamically configuring themselves to or- 
chestrate local, peer, and network resources according to the 
preferences and profiles of the respective user, policies of 
the respective systems and network providers in a coordinated 
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manner among a multiplicity of heterogeneous applications and 
middleware used by various peers. 

In the European patent application EP 01 122 366.6, the over- 
5 all E2ENP concept, its requirements, and a possible implemen- 
tation idea thereof is disclosed, however, without detailing 
any implementation. Any pre-negotiated information is not ac- 
complished in time. 

10 Although the current form of SDPng as described in [Kut2] is 
structured in a modular way, it does hot' consider E2ENP as- 
pects and can not be used in a modular way across different 
SIP messages (or other protocol messages) . Capability nego- 
tiations based on SDPng use the SDP Offerer/Answerer model 

15 described in [Ros2], in which complex multi-phase negotiation 
processes such as the one proposed in the scope of E2ENP are 
not explicitly taken into account. 

A process capable of considering user profile information as 
20 input for the overall QoS negotiation process is neither ad- 
dressed in the European patent application EP 01 122 366.6 
nor in SDPng. 

OBJECT OF THE UNDERLYING INVENTION 

25 

In view of the explanations mentioned above, it is the pri- 
mary object of the underlying invention to propose a negotia- 
tion method and a software architecture supporting capability 
and QoS negotiation and session establishment combined with 
30 resource reservation mechanisms for adaptive real-time serv- 
ices and multimedia applications. 

This object is achieved by means of the features of the inde- 
pendent claims. Advantageous features are defined in the sub- 



P 26921 EP and P 26922 EP 

10 



ordinate claims. Further objects and advantages of the inven 
tion are apparent in the following detailed description. 

SUMMARY OF .THE UNDERLYING INVENTION 

The underlying invention is basically dedicated to the con- 
cept and realization of a novel User Agent (UA) for an End- 
to-End Negotiation Protocol (E2ENP) - a software module en- 
capsulating the end-to-end signaling processes of the E2ENP 
as described in [ReqSpec] which can advantageously be ap- 
plied to define user profile ahd terminal capability inf brma 
tion in such a way that hierarchical QoS Contract specifica- 
tions, (e.g. compelling correlations, across different sets of 
QoS Contracts for related media streams) can be enforced and 
used for deriving negotiable information. As a reference im- 
plementation of this concept, this invention describes a 
novel usage of the Session Initiation Protocol (SIP) stan- 
dardized by. the Internet Engineering Task Force (IETF) in 
conjunction with extensions of the Session Description Proto- 
col - Next Generation (SDPng) specification based on the Ex- 
tensible Markup Language (XML) in order to implement End-to- 
End QoS Negotiation Protocol (E2ENP) concepts. More specifi- 
cally, the hereby proposed model extends the SDPng negotia- 
tion mechanisms by defining user profile and terminal capa- 
bility information, which allow to enforce and use hierarchic 
cal QoS Contract specifications. 

Thereby, said End-to-End Negotiation Protocol (E2ENP) is ap- 
plied to derive negotiable information, which enables a pre- 
negotiation, fast negotiation and a fast, dynamic re-negotia- 
tion of the end-to-end quality and capabilities for a tele- 
communication session, for multiple configurations of two or 
a multiplicity of end peers and/or middleware in a consis- 
tent, reliable, and incremental way by enabling the mobile 
applications to efficiently and timely react to QoS viola- 
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tions. Furthermore, the invention pertains to the concept and 
realization of a novel E2ENP User Agent which encapsulates 
the signaling part of E2ENP. Said E2ENP User Agent expresses 
the information to be negotiated in an interchangeable format 

5 in such a way that heterogeneous applications can easily 
agree on a reference model, which can then be used for dy- 
namically configuring Finite State Machines to orchestrate 
local, peer, and network resources according to the prefer- 
ences and profiles of the respective user in a coordinated 

10 manner . 

According to the underlying invention, the conversation of an 
interchangeable format between an internal (application- and/ 
or middleware-specific) and an external (SIP User Agent spe- 

15 cific) representation is performed by a Parser and a. Factory , 
implementation* These software components are also configur- 
able according to the specific needs of the underlying car- 
rier protocol agent, the E2ENP User Agent, and the respective-, 
application and/or middleware. In this connection, the spe- 

20 cific E2ENP User Agent session identification and the respec— 
tive application and/or middleware session identification of 
the applied negotiation processes and sub-processes are 
uniquely mapped to each other and cached in order to be able 
to uniquely identify pre-negotiation, negotiation and/or re- 

25 negotiation sessions. Thereby, the Parser, the Factory, and 
the Cache are coupled with the implementations of the respec- 
tive E2ENP User Agent. It should be noted that the configura- 
tion of these four software components - Parser, Factory, 
Cache, and E2ENP User Agent - and the User Agent of the ap- 

30 plied carrier protocol is an application-specific task, which 
depends on the needs of the respectively employed application 
and/or middleware component. 



| 
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-BRIEF DESCRIPTION OF THE DRAWINGS 

Further advantages and possible applications of the underly- 
ing invention result from the subordinate claims as well as 
from the following description of the preferred embodiment of 
the invention, illustrated by the following figures and ta- 
bles: 

Fig. 1 presents a block diagram showing the applied architec- 
ture for the User Agent (UA) of the End-to-End Negotia- 
tion Protocol • (E2ENP) according to the underlying inven- 
tion, 

Fig. 2 shows- a first implementation example of the applied ar- 
chitecture for the User Agent (UA) of the End-to-End Ne- 
gotiation Protocol (E2ENP) according to one embodiment 
of the underlying invention using a Java-based SIP stack 
(JSIP), an SDPng Parser and Factory, 

Fig. 3 shows a second, implementation example of the applied ar- 
chitecture for the User Agent (UA) of the End-to-End Ne- 
gotiation Protocol (E2ENP) according to one embodiment 
of the underlying invention using Sun' s Java Remote 
.•Method Invocation (RMI) , 

Fig. 4 • shows a third implementation example of the applied ar- 
chitecture for the User Agent (UA) of the End-to-End Ne- 
gotiation Protocol (E2ENP) according to one embodiment 
of the underlying invention using the socked-based User 
Datagram Protocol (UDP) or Transmission Control Protocol 
(TCP) ,. 

Fig. 5 exhibits a UML class diagram showing the 
org: : mind: :e2enp package, 

Fig. -5 bl3 shows the E2ENP Management API between the E2ENP UA Fac- 
tory and the Management Entities, 

Fig. 6 presents a document showing examples for the syntax of 
the E2ENP Universal Resource Identifier (uri), thereby 
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using the Augmented Backus-Naur Form (ABNF) , 
Fig. 7 outlines a first message sequence chart (MSG) showing 

the pre-negotiation procedure enabled by the User Agent 

(UA) of the proposed End-to-End Negotiation Protocol 

(E2ENP) , 

Fig. 8 outlines a second message sequence chart (MSC) showing 

the session establishment with a QoS negotiation and re- 
source reservation coordination enabled by the User . 
Agent (UA) of the proposed End-to-End Negotiation Proto- 
col (E2ENP) , 

Fig, 9 exhibits a UML class diagram showing the 
org: : mind: :e2enp: : Cache sub-package, 

Fig, 10 presents a diagram showing the top-level view of an Ex- 
tensible Markup Language (XML) description used for the 
End-to-End Negotiation Protocol (E2ENP) , 

Fig. 11 presents a diagram showing the XML substitution groups 
used for the End-to-End Negotiation Protocol (E2ENP ). , 

Fig. 12 presents a diagram showing the XML purpose element used 
for the End-to-End Negotiation Protocol (E2ENP) , 

Fig. 13 presents a diagram showing the XML qosdef element used 
for the End-to-End Negotiation Protocol (E2ENP) , 

Fig. 14 presents a diagram showing the XML qoscfg element used 
for the End-to-End Negotiation Protocol (E2ENP) , 

Fig. 15 exhibits a UML message sequence chart (MSC) showing the 
interaction between the E2ENP User Agent (E2ENP UA) ac- 
cording to the underlying invention and the applied 
Parser and Cache, 

Fig. 17 exhibits a UML class diagram showing the general struc- 
ture of a Document Object Model (DOM) tree, 

Fig. 18 exhibits a UML class diagram showing a structural over- 
view of the Parser implementation using a visitor design 
pattern, 

Fig. 19 presents a UML message sequence chart (MSC) showing the 
interaction between the E2ENP User Agent (E2ENP UA) ac- 
cording to the underlying invention and the applied Fac- 
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tory and Cache/ 

Fig. 20 presents a UML class diagram showing a structural over- 
view of the Factory implementation, 

Fig. 21 exhibits a UML class diagram showing the 
org: :mind: :sip: :sipApi package, 

Fig. 22 exhibits a UML class diagram showing the 
org: :mind: :sip: :sipApi: :userAgent package. 

Fig. 23 exhibits a UML class diagram showing the 

org: :mind: :sip: :sipApi: .-registrar package, 

Eig.. 24 exhibits a UML class . diagram showing the 

org: : mind: : sip: .-sipApir : management package, 

Fig. 25 exhibits a UML class diagram showing the 
org: :mind: : sip: :.sipApi: : time package, 

Fig. 26 exhibits a UML message sequence chart (MSC) showing the 
configuration of the Service Provider and the binding of 
the service User with said Service Provider, 

Fig. 27 exhibits a UML message sequence chart (MSC) showing the 
connection establishment between the User Agents of a 
client and a server, 

Fig. 28 exhibits, a UML message sequence chart (MSC) showing the 
OPTIONS method used for the End-to-End Negotiation Pro- 
tocol (E2ENP) , 

Fig. 29 exhibits a UML message sequence chart (MSC) showing the 
connection release between the User Agents of a client 
and a server, 

Fig. 30 shows a first state transition diagram for a nested Fi- 
nite State Machine .( FSM) showing the mutex-related pro- 
cedures executed : in the root state, 

Fig. 31 shows a second state transition diagram for a nested Fi- 
nite State Machine (FSM) showing the mutex-related pro- 
cedures executed in the NegOfferer sub-state, 

Fig. 32 shows a third state transition diagram for a nested Fi- 
nite State Machine (FSM) showing the mutex-related pro- 
cedures executed in the NegAnswerer sub-state, 

Fig. 33 shows a fourth state transition diagram for a nested Fi- 
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nite State Machine (FSM) showing the mutex-related pro- 
cedures executed in the ReNegOfferer sub-state. 

Fig. 34 shows a fifth state transition diagram for a nested Fi- 
nite State Machine (FSM) showing the mutex-related pro- 
cedures executed in the ReNegAnswerer sub-state. 

Fig. 35 shows a sixth state transition diagram for the „_Resv- 
Mtx" Finite State Machine (FSM) for allowing multiple 
requests to seize the mutex in a coordinated manner, 
based on their priority, 

Fig. 36 shows a seventh state transition diagram for a nested 
Finite State Machine (FSM) showing the mutex-related 
procedures executed in the Wait For CoordDone sub-state> 

Fig. 37 exhibits a UML message sequence chart (MSC) showing the 
pre-negotiation procedure needed for the correlation of 
the Application Programming Interface (API) of the E2ENP 
User Agent (E2ENP UA) and the generic Application Pro- 
gramming Interface (API) of the SIP User Agent (SIP UA) , 
thereby using the above-mentioned Finite State Machine 
(FSM) of the E2ENP User Agent (E2ENP UA) , 

Fig. 38 exhibits a UML message sequence chart (MSC) showing the 
session establishment with the QoS negotiation procedure 
and the resource reservation coordination needed for the 
correlation of the Application Programming Interface 
(API) of the E2ENP User Agent (E2ENP UA) and the generic 
Application Programming Interface (API) of the SIP User 
Agent (SIP UA) , thereby using the above-mentioned Finite 
State Machine (FSM) of the E2ENP User Agent (E2ENP UA) , 

Tab. 1 shows a list of primitives implemented by the Service 

Provider, based on a Java implementation of the Applica- 
tion Programming Interface (API) applied to the User 
Agent (UA) of the End-to-End Negotiation Protocol 
(E2ENP) , 

Tab. 2 shows a list of primitives to be implemented by the 

Service User, based on a Java implementation of the Ap- 
plication Programming Interface (API) applied to the 
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User Agent (UA) of the End-to-End Negotiation Protocol 
(E2ENP) , 

Tab. 3 shows a list of primitives to be implemented by the 

Service User acting as an Offerer, based on a Java im- 
plementation of the Application Programming Interface 
(API) applied to the User Agent (UA) of the End-to-End 
Negotiation Protocol (E2ENP) , 
Tab. 4 shows a list of primitives to be implemented by the 

Service User- acting as an Answerer, based on a Java im- 
plementation of the Application Programming Interface 
(API) applied to the User Agent ' (UA) of the End-to-End 
Negotiation Protocol (E2ENP) , 
Tab. 5 shows the methods provided by the Application Program- 
ming interface (API) of the first Cache level, 
Tab. 6- shows the methods provided by the Application Program- 
ming Interface (API) of the second Cache level, 
Tab. 7 shows a list of primitives which have to be implemented 
by the Application Programming Interface (API) of the 
Parser, 

Tab. 8 shows a list of primitives which have to be implemented 
for generating a specific Parser instance, 

Tab. 9 shows a list, of primitives which have to be implemented 
by the Application Programming Interface (API) of the 
Factory, 

Tab. 10 shows a list- of primitives which have to be implemented 

for generating a specific Factory instance, 
Tab. 11 shows the methods provided by the well-known Factory- 
Factory class E2ENPContentHandlerFactory, 
Tab. 12 shows a list of primitives implemented by the Service 

Provider of the User Agent (UA) of the End-to-End Nego- 
tiation Protocol (E2ENP) , based on a Java implementation 
of the generic Application Programming Interface (API) 
applied to the User Agent (UA) of the End-to-End Nego- 
tiation Protocol (E2ENP) , 

shows a list of client-side-specific primitives imple- 



Tab. 13 
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mented by the Service User, based on a Java implementa- 
tion of the generic Application Programming Interface 
(API) applied to the User Agent (UA) of the End-to-End 
Negotiation Protocol (E2ENP) , 

Tab. 14 shows a list of server-side-specific primitives imple- 
mented by the Service User, based on a Java implementa- 
tion of the generic Application Programming Interface 
(API) applied to the User Agent (UA) of the End-to-End 
Negotiation Protocol (E2ENP) , 

Tab. 15 shows a list of both client-side- and server-side- 
specific primitives implemented by the Service User, 
based on a Java implementation of the generic Applica- 
tion Programming Interface (API) applied to the User 
Agent (UA) of the End-to-End Negotiation Protocol 
(E2ENP) , 

Tab. 16 shows a list of primitives implemented by the Service 

Provider, based on a Java implementation of the generic 
Application Programming Interface (API) applied to the 
User . Agent (UA) of the End-to-End Negotiation Protocol 
(E2ENP) , 

Tab. 17 shows a list of primitives implemented by the Service 

User, based on a Java implementation of the generic Ap- ' 
plication Programming Interface (API) applied to the 
User Agent (UA) of the End-to-End Negotiation Protocol 
(E2ENP) , 

Tab. 18 is a state transition table showing a survey of the ap- 
plied exception events, and 

Tab. 19 shows the applied timers applied to the End-to-End Nego- 
tiation Protocol (E2ENP) according to the underlying in- 
vention. 
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DETAILED DESCRIPTION OF THE UNDERLYING INVENTION 

According to one embodiment of the underlying invention, an 
E2ENP UA 128 supports the following platforms: Win32 and 
Linux. Quality, robustness, maintainability, extensibility, 
flexibility and efficiency are the challenges to the archi- 
tecture and its solutions. 

- Quality includes testability and verification of the system 
already during development. Robustness is the ability of 
the system to stay stable and available also in error 
situations. Both aims directly affect the availability and 
acceptance of the system. 

- Maintainability and extensibility include all costs of the 
system in later phases (concerning both error correction 
and extensions) . These costs must be minimized. 

- Flexibility also addresses the point that changes should be 
. applied as.cos.t-ef fective as possible. 

- Efficiency addresses minimization of resource usage (con- 
cerning memory and processor) . 

For the architecture; the following basic conceptual and 
technical requirements can be derived: 

♦ definition of design components with well chosen and de- 
fined responsibility and features; 

♦ small dependencies between design components (loose cou- 
pling), so that changes have only a limited effect; 

♦ minimum resource consumption, especially concerning the 
applied Random Access Memories (RAMs); 
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♦ a strict separation between interface and implementation 
(a change of the implementation shall not affect the in- 
terface) ; 

♦ definition of restrictions, if this simplifies the reali- 
5 zation concept - however, restrictions and their effects 

must be negotiated with the stakeholders. 

The E2ENP UA 128 depicted in Fig. 1 is designed as a software 
component which communicates with the environment through the 
10 following five APIs: 

• E2ENP Management API 101a (IF1) : This API represents the 
interface between the E2ENP UA 128 and any entities 102 
managing it, in the sense of configuration, monitoring, and 

15 control . 

• E2ENP UA API 101b (IF2) : This API represents the interface 
between the E2ENP UA 128 and any application 130 or middle- 
ware using the services offered by said E2ENP UA 128. The. 

20 information exchanged through this API can be modeled as an 
object structure or as an XML-based document, to be accord- 
ingly interpreted by applications 130 or middleware 130- 
placed on top of the E2ENP UA 128. , 

25 • SIP UA Generic API 101c (IF3) : This API represents the in- 
terface between the E2ENP UA 128 and the session-layer pro- 
tocol used for implementing the E2ENP-specif ication. The 
name of this API clearly indicates that the Session Initia- 
tion Protocol (SIP) described in [Rosl] is used as a refer- 

30 ence session-layer protocol* However, with minor modifica- 
tions, this API can easily be generalized in a future de- 
sign review, so as to remove the E2ENP UA dependency on the 
SIP. Nevertheless, by using this design it would be possi- 
ble to have a complete Java Remote Method Invocation (RMI) 

35 implementation of the SIP UA Generic API 101c (IF3) . 
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• Parser API lOld (IF4) : This API represents the interface 
between the E2ENP UA 128 and any Parser implementation 112 
used for decoding the E2ENP session description. 

5 

• Factory API lOle (IF5) : This API represents the interface 
between the E2ENP UA 128 and any Factory tool 114 used for 
encoding the E2ENP session description. 

10 Internally, the E2ENP UA 128 is composed of different Finite 
State Machines 106 (FSMs) handling the coordination of the 
procedures associated with the aforementioned interfaces, and 
their interrelations; More specifically, the E2ENP UA 128 
should feature a client FSM 106 and a server FSM 106 for in- 

15 dependently and simultaneously handling, respectively, the 
initiation of an E2ENP (pre-) negotiation and/or session es- 
tablishment, and the response to such procedures. This means 
mapping primitives of the interface 101b (IF2) to primitives 
of the interface 101c (IF3), and vice versa. The mapping of 

20 the primitives concerns both object and object identifiers 

mapping. The mapped objects and the identifiers are stored in 
a respective Cache 104 at the E2ENP UA 128 and/or at the ap- 
plication 130 above IF2. 

25 During this mapping process, the E2ENP UA FSMs 106 should 
: also be able to access the interfaces lOld (IF4) and lOle 
(IF5) for handling, respectively, E2ENP session description 
decoding and encoding. 

30 The Parser and Factory implementations 112 and 114, respec- 
tively, though essential entities for implementing the E2ENP 
concept, are designed as separated software components, inso- 
far as they can be implemented in various ways (based on SDP, 
SDPng, SDPng dialects, or any other session description lan- 

35 guages of choice) . 
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rn the following subsection, the basic problem domains of the 
system shall be described and how they are solved within the 
E2ENP UA 128. Each problem domain is discussed individually 
5 and across the system. It refers to other problem domains if 
there is any interference with them or if a part of the prob- 
lem domain is discussed more detailed in an extra section. 

The E2ENP UA 128 is designed according to the object-oriented 
10 paradigm, and a Java-based prototype based on such design is . 
hereby described. It allows using various types of XML pars- 
ing tools (through IF4) and various session level protocols 
(through IF3) to transport E2ENP primitives. The hereby- . 
described prototype based on the aforementioned E2ENP UA de- 
15 sign uses SIP as described in [Rosl] as session-layer proto- 
cols. Various SIP implementations are supported by the E2ENP 
UA design, thanks to the abstract nature of IF3. 

In the scope of the underlying invention, both the E2ENP UA 
20 FSM 106 and the SIP UA Generic API (IF3) are explicitly de- 
signed to support SIP. It is foreseen that in a future design 
review these dependencies will be removed by making IF3 even 
more abstract. The E2ENP UA 128 will also be able to simulta- 
neously support multiple users of multiple applications 130. 
25 using multiple instances of the E2ENP UA services. 

The E2ENP UA 128 supports three types of object categories: 
identifiers (IDs) , description objects (object graphs or a 
formal description of an object graph, like XML) and event 
30 objects. These categories correspond to the objects passed to 
the agent through IF2, IF3, IF4, and IF5 in both directions. 



35 



- The IDs are needed to uniquely identify the session de- 
scription objects. There are two types of identifiers, 
which are also objects: 
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• E2ENP internal object IDs, corresponding to the objects 
processed within the E2ENP UA FSMs 106, 

• application IDs pointing also at the respective E2ENP UA 
FSM 106 objects, which are used by an application 130 to 
steer negotiation events. 

- The session description objects are either object graphs 
used by the E2ENP UA FSM processing or external descrip- 
tions used by. the. Parser .implementation 112,. the Factory 
implementation 114, and the E2ENP UA 128 by a negotiation 
process. All these session description objects can persis- 
tently be saved by the application 130 (above IF2) using 
them. The management (leasing descriptions, refreshing of 
leased descriptions, etc.) of the saved objects is an ap- 
plication-specific task. 

- The event objects correspond to application negotiation 
events, which affect the E2ENP UA FSM 106 functionality by 
triggering adaptation sequences . 

The IDs, the E2ENP UA FSM object graphs and the event objects 
are Java objects. The external protocol representations can 
be SDP, SDPng, SDPng dialects, or any other session descrip- 
tion language objects of choice. The implementation of the 
Java objects passed through interface IF2 depend on the in- 
terface definition of IF2. The objects passed through the in- 
terfaces IF4 and IF5 are either E2ENP UA FSM 106 object rep- 
resentations or external protocol representations. The ob- 
jects passed through IF3 are external protocol representa- 
tions. All the external representations of the session de- 
scription objects passed through IF3, IF4 and IF5 should im- 
plement java.io.Serializable in order to be compatible with 
the SIP Surrogate RMI implementation. 
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The internal representations of the session description ob- 
jects passed over the IF2, IF3, ' IF4 and IF5 shall be typed as 
java.lang. Object and should be cast into the expected type by 
5 the E2ENP UA 128 , the Parser 112, and the Factory 114. This 
requirement is necessary to keep the SIP UA 110 and the im- 
plementations of the Parser 112 and the Factory 114 modular 
by leveraging generic APIs . 

10 The following section contains a brief survey of the applied 
implementations of the Parser 112 and the Factory 114. 

Since the negotiation process involves at least two entities 
interconnected by a network, it is necessary to provide map- 

15 ping functionality from system- internal representation to a 
transport representation over the network and back. The 
mechanisms that provide this mapping are called Parser API 
lOld (in the following referred to just as Parser 112) and 
Factory API lOle (referred to as Factory 114) , where the 

20 Parser 112 takes an object encoded in network representation 
as input and generates a system-internal representation of 
said object. In contrast, the Factory 114 generates a network 
representation for a given system- internal representation. 

25 The need for said Parser API lOld, said Factory API lOle and 
the functionality defined by them arises from the facts that 
the system- internal representation may not be appropriate for 
a transport representation that can be sent over networks and 
the transport representation may not be adequate for a sys- 

30 tern-internal representation. 

Additionally, introducing these components into the system 
decouples the higher application layer from the lower trans- 
port-oriented layers. As a consequence, the actually used 
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transport protocol is of no concern to the upper application 
layers and should ideally be pluggable. 

The use of the Extensible Markup Language (XML) as transport 
syntax is motivated by the widespread adoption of XML as an 
industry standard, and it also allows for the incorporation 
of external features (SDPng libraries and profiles) and pro- 
vides compatibility to related work (SDPng schema) . Another 
feature of XML is its simple extensibility. 

As described above, the use of different carrier protocols 
requires that the Parser 112 and the Factory 114 are config- 
urable by the same means as the protocol, which means that in 
case the protocol is configurable at runtime, said Parser 112 
and said Factory 114 might also have to be changed while the 
system is running. This implies the specification of an ab- 
stract interface, since the actual implementations depend on 
the specific underlying carrier protocols. 

Concrete Factory 114 implementations for different carrier 
protocols will produce different results. For example, an RMI 
factory may just be a dummy implementation. It is thus possi- 
ble to transfer Java objects, e.g. the objects „as is", di- 
rectly over a network connection by simply using Java Remote 
Method Invocation (RMI) . 

If SIP is used as a carrier protocol, however, an external 
representation (more specifically a protocol data unit or 
PDU) to be sent over the network has to be generated. Possi- 
bilities include but are not limited to some proprietary text 
format similar to SDP, for example, or a more structured ap- 
proach using XML, as e.g. SDPng does. 

The API definitions for the Parser API 10 Id and the Factory 
API lOle are un-typed in order to support loose coupling of 
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the E2ENP UA 128 and the Parser 112 as well as the Factory 
114. The transport representation as described above is im- 
plemented by just using the java. io . Serializable interface, 
which is inherently un-typed. The system-internal representa- 
5 tion is chosen to be the represented as java. lang. Object . The 
matching between the actual implementations of the Parser 112 
and the Factory 114 and the object representation used in the 
E2ENP UA 128 have to be established by configuration. 

10 The mechanism is implemented by the following two software 
components : 

♦ Parser API lOld: Primitives of this API should accept as 
parameters any object implementing the java.io.Serializ- 

15 able interface. The result of the parsing process yields 

an object representation according to IF2, which will ab- 
stractly be typed as java. lang. Object. 

♦ Factory API lOle: Primitives of this API should accept as 
20 parameter any object representation according to IF2, 

which will be abstractly typed as java. lang. Object and 
generate a representation conforming to the 
java. io. Serializable interface. 

25 Additionally/ in order to achieve configurability, the use of 
a ^factory design pattern" for creating Parser 112 and Fac- 
tory 114 instances is a possible solution. For this purpose, 
the factory method is parameterized with the transport proto- 
col (the distinguishing feature of different Parser 

30 112/Factory 114 implementations) . If dynamic support for dif- 
ferent carrier protocols is needed, the factory classes have 
to provide a registration procedure for new protocols. 
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In the next section, the use of SIP surrogates shall briefly 
be described. 

The applied SIP UA Generic API 101c (IF3) requires the avail- 
ability of a SIP UA implementation which supports such an 
API. Similarly, the Parser API lOld (IF4) and the Factory API 
lOle (F5) presume the availability of parser and factory im- 
plementations compatible with the UA implementation 110, re- 
spectively. In order to allow validating and rapidly proto- 
typing the E2ENP model, IF3, IF4, and IF5 have been designed 
in such a way that surrogates' of real SIP UA implementations 
and of compatible Parser 112 and Factory 114 implementations 
can be used as handy alternatives for experimental purposes. 

By using a. legacy implementation (already provided code/API 
and/or software, possibly from an external implement er) of 
the SIP UA 110 for testing and/or updating the E2ENP UA 128 > 
it might be sometimes difficult to establish the connection' 
between the E2ENP UA 128 and the SIP UA 110, as the interface 
provided by the legacy SIP implementation may not match di- 
rectly the interface 101c required by the E2ENP UA. In gen- 
eral, using a SIP UA 110 to provide network connectivity for 
the E2ENP UA 128 is not recommended whenever testing new 
E2ENP UA 128 features, due to. possible conceptual contradic- 
tions between the protocol agents (SIP and E2ENP) . These con- 
tradictions may result in specification changes of the car- 
rier protocol - SIP, that is why for the tests of the E2ENP 
UA 128 the usage of a SIP emulator (which can easily adopt 
conceptual changes) is preferable. 

In order to carry out a SIP emulation, SIP surrogates (e.g. 
Remote Procedure Call mechanisms, RPCs) can be employed. When 
E2ENP session description payloads have to be tested without 
necessarily using „full-blown- Parser 112 and Factory 114 im- 
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plementations, solutions coupled with the chosen SIP surro-^ 
gate can also be applied. 

As mentioned above, a prototype E2ENP UA 128 implementation 
5 based on the hereby-presented architectural model has been 
selected for demonstrating the E2ENP concept. Since this im- 
plementation is based on Java, an RPC-based, built-in Java 
RMI mechanism has been selected as SIP surrogate. 

10 Since RMI takes care of marshalling or demarshalling the SIP 
UA Generic API 101c (IF3) primitives payload directly, all 
the parameters passed to the API have to implement the java. 
io. Serializable interface. 

15 In order to test E2ENP session description payloads without 
necessarily using „full-blown" Parser 112 and Factory 114 im- 
plementations (for the same reasons set forth above for the 
use of SIP surrogates) , passing such content through the IF3 
as a string might be not necessary as RMI can process ob- 

20 jects. Rather, a whole object structure representing a given 
E2ENP session description payload might be exchanged directly 
through the RMI marshalling or demarshalling mechanism. 
Therefore, the prototype E2ENP UA 128 implementation based on 
the hereby-presented architectural model has been designed in 

25 such a way that the IF3 primitives shall accept as parameters 
any object implementing the java.io. Serializable interface, 
and not just instances of the java . lang. String class. 

Said mechanism is implemented by the following software com- 
30 ponents : 

♦ SIP UA Generic API 101c: Primitives of this API shall ac- 
cept as parameters any object implementing the java.io. Se- 
rializable interface, and not just instances of the java. 
35 lang. String class. A SIP UA 110 implementation shall inter- 
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pret the passed objects as instances of the java.lang. 
String class via casting mechanism. The RMI surrogate SIP 
implementation shall directly serialize or deserialize the 
aforementioned objects „as is". 

♦ Parser API lOld: Primitives of this API shall accept as pa- 
rameters any object implementing the java. io. Serializable 
interface. 

♦ Factory API iOle: Primitives of this API shall accept as 
parameters any object implementing the java.io. Serializable 
interface. 

Fig. 2 shows an implementation of the architectural model as 
mentioned above, based on a specific SIP UA 110 implementa- 
tion (e.g. a Java based SIP stack - JSIP) , and on Factory 114 
and Parser 112 implementations handling a modified version of 
SDPng. 

Fig. 3 shows an implementation "of the architectural model 
mentioned above, based on an RMI SIP surrogate: In this case, 
the Factory 114b and Parser li2b implementations are simply 
dummies. 

The Dummy ParserFactory 118b and the Dummy FactoryFactory 
120b respectively create the „Dummy Parser" runtime instance 
112b and the „Dummy Factory" runtime instance 114b. 

Though indicated as „dummy", still, said Parser 112b and said 
Factory 114b could check and/or enforce that the objects used 
in the object graph are typed as „ java.io. Serializable" . 

Fig. 4 shows an implementation of the architectural model 
mentioned above, using a socket-based SIP surrogate: in this 
case, the Factory 114c and Parser 112c implementations are 
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simply dummies. Nevertheless, one could also use the SDPng 
parser 112a and SDPng Factory 114a to send XML based strings 
across the sockets using a proper Adapter 126c. The primi- 
tives are manually mapped into messages to be sent over sock- 
5 ets, thus implementing a proprietary Remote Procedure Call 
(RPC) mechanism. 

The Dummy FactoryFactory 120c and Dummy Parser Factory 118c . 
create respectively the „Dummy Parser" runtime instance 112c 
10 and the „Dummy Factory" runtime instance 114c. 

Though indicated as „dummy", still, said Parser 112c and said 
Factory 114c could check and/or enforce that the objects used 
in the object graph are typed as „java. io .Serializable" . 

15 

In the following subsections, the software components applied 
within the scope of the E2ENP UA 128 according to the under- 
lying invention shall briefly be described from the viewpoint 
of the component. For each software component, its require- 
20 ments, offered services and constraints are described and 
also its relations to other software components. This de- 
scription serves as the basis for the detailed design. 

Fig. 1 shows all software components and their usage rela- 
25 tions. A software component is assigned to a layer and may 

have relations to components on the same or a lower layer but 
not to software components on a higher layer. The layers do 
not have the strict meaning of encapsulating a lower layer. 

30 Accordingly, the entity using the services offered by a given 
API will be referred to as Service User, whereas the entity 
implementing the services of said API will be referred to as 
Service Provider. 
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The E2ENP UA API 101b (the aforementioned IF2) exposes the 
E2ENP UA functionality to Service Users like QoS-aware appli- 
cations 130 and/or QoS Brokers 130, according to the BRENTA 
model as described in [BRENTA] . This component realizes the 
specification of a generic API by defining a set of inter- 
faces and complex data types exchanged through said API . 

Thereby, said E2ENP UA API 101b allows multiple instances of 
Service Users to simultaneously access the E2ENP UA 128 func- 
tionality. More specifically, the E2ENP UA 128 offers the 
following services as described in [ReqSpec] : 

1. pre-negotiation. of a multiplicity of alternative capa- 
bilities and/or QoS Contracts (at both application and 

. network level);. 

2. management . of leased pre-negotiated information; 

3. session establishment with negotiation of a multiplicity 
of alternative capabilities and/or QoS Contracts (at 
both application and network level), potentially refer- 
encing pre-negotiated information; 

4. same as point 2, but with additional local, peer, and 
network resource reservation coordination; 

5. re-negotiation, similar to points 2 and 3; 

6. session release, with potential reservation release co- 
ordination.. 

In order to expose these services, the E2ENP UA API 101b 
shall expose, respectively, the following primitives: 

1 . pre-negotiation; 

2. leaseRenewal, which can be used for refreshing or termi- 
nating a lease; 

3 . negotiation, parameterized to indicate whether resource- 
reservation coordination is required. If resource reser- 
vation coordination is required, the E2ENP UA 128 allows 
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the Service User at the Offerer side to book the mutu- 
ally exclusive access to the resource reservation phase 
via the bookNegotiation and/or bookRenegotiation primi- 
tive; 

5 4. re-negotiation: If resource reservation coordination has 

been specified as required in the original negotiation 
phase, the E2ENP UA 128 allows the Service User at the 
Offerer side to book the mutually exclusive access to 
the resource reservation phase via the bookRenegotiation 
10 primitive; 
5. release. 



The E2ENP UA API 101b has been designed based on the follow- 
ing design principles: 

15 

1. Primitives are classified into Request (Req) , Indication 
(Ind), Response (Rsp) , and Confirmation (Cfm) primitives, 
according to the ISO/OSI model. Request (Req) and Response 
(Rsp) primitives are invoked by the client application 130 

20 or middleware 130 implementation (also known as Service 

User) , in order to respectively initiate or respond to a . 
particular message exchange. (In some cases the message 
exchange may involve a set of different messages being ex- 
changed between peers, thanks to the abstraction offered 

25 by the given E2ENP UA implementation, whereas in other 

cases the message exchange is limited to the given message 
and its acknowledgment.) Indication (Ind) and Confirmation 
(Cfm) primitives are invoked by the E2ENP UA 128 (also 
known as Service Provider) to the registered client-side 

30 of the Service User 130, in order to respectively indicate 

the arrival of a particular message exchange or to confirm 
the conclusion of a given message exchange. (Again, in 
some cases the message exchange may involve a set of dif- 
ferent messages being exchanged between peers, thanks to 

35 the abstraction offered by the given Service Provider, 
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whereas in other cases the message exchange is limited to 
th^ given message and its acknowledgment.) The client-side 
of the Service User 130 must implement these primitives. 
To a. request primitive generated by the peer initiating 
5 the given protocol message . exchange, corresponds an Indi- 

cation (Ind) primitive -at the target peer. To a Response 
(Rsp) primitive generated by the target peer, responding 
to the given protocol message exchange, corresponds a Con- 
firmation (Cfm) primitive at the initiating peer. 

10 

2. In order to distinguish different Service Users 130, the 
E2ENP UA 128 exposes at interface 101b (IF2) one Service 
Access Point (SAP) per registered Service User 130. 
Thereby, any given Service User 130 can use. more than one 

15 SAP at said interface 101b (IF2) in a one-to-many rela- 

tionship. • 

3. Users can only be registered with one Service User 130 at 
a time, which means that each user will be associated with 

20 at most one SAP at said- interface 101b (IF2) . 

4. In order to simultaneously and independently use different 
session layer protocols 110 (e.g. various SIP implementa- 
tions and/or RMIs) the E2ENP UA 128 exposes at interface 

25 101c (IF3) one SAP per registered session layer protocol. 

5. In order to properly associate Service Users 130 with un- 
derlying session layer protocols, the E2ENP UA 128 exposes 
at interface 101a (IF1) proper configuration mechanisms, 

30 which allow associating SAPs at interface 101b (IF2) with 

SAPs at interface 101c (IF3) in a one-to-one relationship. 
In this way, user using a given type of application 130 
will automatically and transparently be using the associ- 
ated session layer protocol as configured. 

35 
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6. When configuring a SAP at interface 101c (IF3), the bind- 
ing of the E2ENP UA 128 to the session-layer protocol 110 
is done automatically* With the given SIP UA 110 Generic 
API at interface 101c (IF3) the binding in the opposite 

5 direction is done when registering a user with the E2ENP 

UA 128, and this leads to a registration of the user to 
the configured session layer protocol 110. 

7. The bidirectional binding of the Service User 130 to the 
10 E2ENP UA 128 is done by means of the bindReq and bindCfm 

primitives, where one of the parameters is a special iden- 
tifier, and the SAP ID (spld) uniquely identifies one of 
the configured SAPs at interface 101b (IF2) . 

15 8. Any given user of any given Service User- 130 registers 
himself /herself on the proper Upper SAP by means of the 
registrationReq and registrationCfm primitives, where one 
of the parameters is the aforementioned spld, which 
uniquely identifies the SAP of choice at interface 101b 

20 (IF2) . 

9. In order to select the proper Upper SAP when locally ini- 
tiating any E2ENP session, the following primitives now 
feature a new parameter „String user" indicating the lo- 

25 cally registered user, which uniquely identifies the SAP 

at interface 101b (IF2) said user is registered to: 

— renewLeaseReq and 

- bookNegotiationReq 

30 

10. To select the proper Upper SAP when locally initiating 
any E2ENP session, the already existing „String form" pa- 
rameter of the following primitives indicates the locally 
registered user, which uniquely identifies the SAP at in- 

35 terface 101b (IF2) said user is registered to: 
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- preNegotiationReq and 

- negotiationReq 

11. The instances of the application or middleware FSM 130 
and of the E2ENP UA FSM 106 are uniquely identified, re- 
spectively, by the serviceUserld and serviceProviderld. 

12. A simplified version of the ^observer design pattern" as 
described in [Gam] (implemented in Java with a derivation 
of the Java Beans event model) offers the mechanism al- 
lowing the Service User 130 to register (via a primitive 
called „Bind Request") for Indication (Ind) and/or Con- 
firmation (Cfm) ' primitive callbacks. 

13. In order to allow supporting E2ENP signaling extensibil- 
ity, most of the primitives allow passing a payload: To- 
day, some of these primitives are in fact not designed to 
carry payloads, but there is a chance that the E2ENP 
specification might be reviewed. Thereby, some additional 
E2ENP information piggybacking could be required. 

14. In order to allow different types of Service Users 130 
accessing the services of the E2ENP UA 110, the payloads 
are typed as the Java root class, java. lang. Object : In 
this way, applications 130 or middleware may use either 
internal custom representations of the information to be 
exchanged via the ~E2ENP (e.g. an XML-based representa- 
tion) , or resort to the default information structure de- 
scribed above. 

Thereby, said E2ENP UA API 101b depends on the respective ap- 
plication 130 and/or middleware 130 using the services of 
said E2ENP UA 128, the applied E2ENP UA FSM 106, concerning 
the implementation of the Request (Req) and Response (Rsp) 
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primitives, and the applied Factory 114 and Parser 112: The 
chosen implementation of these components dictates the type 
of representation used for the information exchanged through 
this API. 

5 

The E2ENP UA API 101b has been designed with the aid of the 
object-oriented paradigm, and is thus hereby described using 
the Unified Modeling Language (UML) . The information to be 
exchanged via the E2ENP is described above. The component is 
10 composed of a basic package, the org: : mind: : e2enp as depicted 
in Fig. 5. 

To this basic package belong the following interfaces: 

15 - The Provider 504 represents the interface that an E2ENP UA 
Service Provider implementation conforming to the herewith 
specification, shall support for implementing Request (Req) 
and Response (Rsp) primitives. Tab. 1 lists the primitives, 
exposed by the Provider interface 504 . 

20 

- The E2ENPUserAgentListener 502 generalizes all the inter- 
faces that Service Users shall implement for intercepting 
Indication and/or Confirmation (Cfm) primitives generated 
by the E2ENP UA 128. 

25 

Tab. 2 lists the primitives exposed by the E2ENPUserAgent- 
Listener interface 502. 

The E2ENPUserAgentListener interface 502 is specialized in 
30 the Of f ererListener interface 50 6 and the AnswererListener 
interface 508. The former is specially designed for the ap- 
plication- or middleware-initiating E2ENP procedures; the 
latter is specially designed for applications 130 or middle- 
ware 130 responding to said E2ENP procedures. 

35 
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Tab. 3 shows the primitives exposed by the Of f ererListener 
interface 506, and Tab. 4 lists the primitives exposed by the 
AnswererListener interface 508 . 

The „to/from»-parameters passed on by the pre-negotiation and 
negotiation primitives are addresses identifying E2ENP users 

(respectively, the Offerer and the Answerer) . The E2ENP UA 
128 maps these addresses to the specific syntax used by the 
given session-layer protocol that is used for piggybacking 
E2ENP information: in the case of this writing, SIP. The 
E2ENP addresses shall therefore be independent of the spe- " 
cific session-layer protocol, and possibly of the transport 
protocol used underneath by the E2ENP UA 128. To this extent, 
a new syntax, which has specially been designed for the 
E2ENP, shall herewith be proposed. 

Fig. 5 bis shows the E2ENP Management API 101a (IF1) between 
the E2ENP UA Factory 108 and the Management Entities 102, de- 
signed by means of the object-oriented paradigm. Thereby, the 
E2ENP Management API 101a (IF1) is composed of a basic pack- 
age, to which the following components belong: the Manager- 
Provider interface 510 and the ManagerListener interface 512. 
For the configuration of the Parser implementation 112 and 
the Factory implementation 114 via said interface IF1, the 
classes Conf igurationReguest 514 and ParserFactoryConf igura- 
tion 516 are used. 

Fig. 6 presents a formal description of such a Universal Re- 
source Identifier (URI) syntax by using the Augmented Backus- 
Naur Form (ABNF) . Thereby, said specification is similar to 
the SIP URI syntax specification described in [Rosl], but de- 
liberately does not indicate any transport protocol parame- 
ter, except for the IP address and/or port number. As an ex- 
ample of E2ENP URI, „e2enp://dave:vG$1809@acme.com" repre- 
sents a user named „Dave« at the „acme" organization, using 
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password „vG$1809". The „//* indication is a form of a sepa- 
rator for default user cases, when the user is not indicated ■ 
in the address. The example „e2enp: // :xyz%45637@acme .com" 
shows a default user (which is not indicated) with a password 
5 „xyz%45637". 

The full or partial usage of the E2ENP address components de- 
pends on the domain model (proxying) and the address resolu- 
tion mechanisms, which are mainly part of the respectively 
10 applied session layer protocol (e.g. SIP) . The E2ENP UA 128 
should use at least the user (default user) name and the do- 
main name to identify the communicating partners, if the ses- 
sion layer protocol is already offering some proxying and/or 
redirection mechanisms to identify the network paths.. 

15 

In the following subsections, the procedures executed by the 
E2ENP UA API 101b shall be described by means of a set of UML 
Message Sequence Charts (MSCs) . 



P 26921 EP and P 26922 EP 

38 



10 



15 



20 



Fig. 7 depicts the simple pre-negotiation scenario in terms 
of an exchange of primitives through the E2ENP API. With re- 
spect to these primitives, specific transport protocol mes- 
sages are exchanged between the Of f ererServiceProvider 704 
and the AnswererServiceProvider 706, but they are not indi- 
cated in Fig. 7 for the sake of generality. 

Fig. 8 depicts the MSC for a simple session establishment 
scenario, wherein QoS negotiation and resource reservation 
coordination processes are highlighted. In the presented sce- 
nario, for the sake of simplicity, the confirmation of re- 
source reservation completion from the Offerer side arrives 
before the same happens at the Answerer side. Likewise, this 
simple scenario assumes for the sake of simplicity that the 
resource reservation process succeeds in reserving exactly 
the amount of resource, which has originally been requested. 

The re-negotiation procedure is similar to the negotiation 
procedure, except that the names of the primitives have been 
changed as follows: 



Old ! Name 


New name 


bookNegotiation<type> 


bookReNegotiation<type> 


negotiation<type> 


reNegotiation<type> 


negotiationStatus<type> 


reNegotiationStatus<type> 



25 



The Cache 104 is a database for saving different object iden- 
tifiers.. In order to decouple the Service User identification 
scheme from the one specified for the E2ENP [ReqSpec] , an 
E2ENP Cache 104 is used for: 



30 
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+ saving and retrieving E2ENP session identifiers specified 
in [ReqSpec], 

♦ saving and retrieving the E2ENP session identifiers han- 
5 died by E2ENP UA FSM 106 (serviceProviderlds) , and 

♦ saving and retrieving E2ENP UA API Service Users' session 
identifiers (serviceUserlds) . 

The Cache 104 should be searchable for different identifiers 
10 and following different criteria set by the E2ENP UA 128. The 
E2ENP UA 128 is responsible for the Cache management. 

The cached objects correspond to the identifier object, cate- 
gory. The Cache 104 maintains two types of data: 

15 

♦ Pre-cached data: The E2ENP UA pre-caches information (in- 
dexed by serviceProviderld as primary key, and service- 
Userld and E2ENP session identifiers specified in [Req- 
Spec] as secondary keys) during the execution of a given 

20 E2ENP pre-negotiation or negotiation procedure. Once the 

given procedure has been successfully completed, the pre- 
cached data remains cached, so that E2ENP UA API 101b 
Service Users have reference to such data during a later 
E2ENP session as described in [ReqSpec] . 

25 

♦ Cached data: This information can be used later, during a 
new E2ENP pre-negotiation or negotiation procedure, as a 
reference to data, which has already been (pre-) negotiated 
among the peers. For each of said E2EPN sessions, the 

30 Cache 104 stores the association between the given Serv- 

iceUserld and the corresponding E2ENP session identifier 
described in [ReqSpec] . Each entry in this Cache 104 is 
leased between peers and should be refreshed over time as 
described in [ReqSpec] . The Service Users 130 themselves 

35 are responsible for managing their own leases and (pre-) 
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negotiated information. The Cache 104 simply stores non- 
persistently the correlations among previous E2ENP ses- 
sions '. 

The E2ENP Cache 104 is a database used for managing" the nego- 
tiation object IDs. The E2ENP UA FSM 106 requests the Cache 
104 services. In an embodiment of this invention, the Cache 
104 is designed as a set of java.util -Hashtable objects ref- 
erencing each other. An alternative implementation based upon 
tupel-space technology is left for further study. 

In order to keep the E2ENP UA 128 implementation simple, the 
Cache API 103 between the Cache 104 and the E2ENP UA FSM 106 
represents a synchronous interface. 

In the implemented version of the underlying invention, a 
two-stage Cache 104 is used: 

♦ Level One (LI) of said Cache 104 saves pre-cached informa- 
tion in form of the following tupel (serviceProviderld, 
serviceUserld, FromSIPAddress, ToSIPAddress, E2ENPSession- 
ID), where the FromSIPAddress and ToSIPAddress allow de- 
tecting dual seizures; the primary key is the service- 
Providerld. 

♦ Level Two (L2) of said Cache 104 saves pre-cached informa- 
tion in form of the following tupel (serviceUserld, 
E2ENPSessionID) , where the primary key is the service- 
Providerld. 

The two levels of the Cache 104 are implemented as two dis- 
tinct singleton objects as described in [Gam], which are ini- 
tiated and managed by the E2ENP UA 128. The Cache objects run 
within the instance of the E2ENP UA 128. Fig. 9 depicts a UML 
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Class Diagram of the org: rmind: : e2enp: : Cache sub-package that 
contains the Cache implementation. 

The singletons LevelOneCache 902 and Level TwoCache 904 re- 
5 spectively represent the Cache level LI and the Cache level 
L2 and provide APIs for creating, searching, and releasing 
Cache entries (LevelOneEntry 906 and LevelTwoEntry 908, re- 
spectively) • 

10 The methods provided by the API of the first and second. Cache 
level (LI and L2) are depicted in Tab. 5 and Tab. 6, respec- 
tively. 

In the following subsection, an XML-based serialized trans- 
15 port representation shall be defined by means of an XML 

schema definition. Rather than defining such a format from 
scratch, the transport representation is based upon and using'', 
the baseline' SDPng format definition. Aside from providing 
compatibility, it is also possible to use and benefit from a / 
20 third-party library and profile definitions designed for 
SDPng as described in [Kut2] . Examples include but are not 
limited to the Real-Time Protocol (RTP) as well as audio and 
video codec profiles. 

25 In order to illustrate how the Factory API lOle and the Par- 
ser API lOld share common transport representation syntax, 
the following subsection provides one possible definition for 
such a format. The XML description of E2ENP extends and uses 
the baseline SDPng XML description format. 

30 

The XML representation for E2ENP (in the following, E2ENP 
will be used synonymously for this representation) has chosen 
to be an extension to the SDPng baseline XML definition. The 
main reason for this decision is that SDPng is expected to be 
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standardized by the IETF, which results in some major bene- 
fits: 



♦ E2ENP as an extension to SDPng will be able to benefit 
from external contributions to SDPng-like profile and li- 
brary definitions. There are already examples pointed out 
in the SDPng draft [Kut2], namely the audio and RTP pro- 
file. These extensions are already incorporated into the 
specification of the E2ENP XML. 

♦ Applications 130 that implement the future SDPng standard 
can more easily be enhanced to also support E2ENP, ideally 
by simply linking the E 2 ENP module to the application 130. 
Likewise, in heterogeneous environments, applications 130 
which do not support E2ENP are still able to work with the 
SDPng-specific parts and do not break interoperability 
completely. 

The E2ENP XML representation is formally specified by an XML 
Schema definition as defined by the W3C. The schema defini- 
tion can roughly be separated into three parts, one contain- 
ing type definitions such as enumerations for attribute val- 
ues or the definition of common content models as complex 
types. The main part defines the top-level E2ENP sections 
(i.e. elements), which are also plugged into SDPng using the 
substitution group mechanism. Finally, the third part defines 
E2ENP- specific elements with no relation to SDPng, which are 
used to completely define the content model of the top-level 
elements . 

As can be seen in Fig. 10, descType 1001 - originally defined 
in SDPng - is redefined in such a way that the E2ENP-specif ic 
header section „purpose" 1002 appears as a legal child of the 
„desc root" element. E2ENP defines a „qosdef" section which 
can be used as a substitute for the „sdpng:d" element, the 
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only valid child for the „sdpng: def * 1003 section, similarly, 
„qoscfg" may be used instead of /,sdpng:c", in turn the only 
valid child for the „sdpng:cfg" 1004 section. The E2ENP- 
specific element types will be described in the following. 

5 

The extensions and plug- ins to SDPng are illustrated in Fig. 
11, which shows how elements in substitution groups can be 
used to replace the head element of this group. 

10 Here, „sdpng:d" 1107 is the head element which may be substi- 
tuted by any of the members of the substitution group, that 
is, „audio:codec" 1108, „e2enp: qosdef M 1109, „rtp:pt" 1110, 
„rtp: transport" 1111 (which in turn again is the head element 
of a nested substitution group) and „video : codec" 1113. Thus, 

15 by using the substitution group mechanism combined with the 
XML namespaces concept, it is possible to define modular ex- 
tensions to any XML schema definition. Additionally, the sub- 
stitution group member „rtp:udp" 1112 can further be enhanced - 
in order to support the option sub-group described in [Bos2], 

20 thereby incorporating an option similar to that suggested by 
[Bos2] (not shown in Fig. 11) . 

The aforementioned „qoscfg" element 1400 is defined in the 
substitution group headed by „sdpng:c M , which in turn is . a 
25 valid child of the „sdpng:cfg" section. 

Using the „purpose" 1201 element depicted in Fig. 12, it is 
possible to convey additional information about the negotia- 
tion process in the external description. The general struc- 
30 ture of how the purpose element is defined is shown in Fig. 
12. 

Thereby, the header defines to which session the current mes- 
sage belongs to. It can also establish references to previous 
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sessions by means of the „use" 1202 element , making it possi- 
ble to reference definitions from these sessions. 

Depending on what the E2ENP message is intended for, either 
5 the description" 1203 or the „mediation" 1204 element should 
be present. For example, with the aid of the ^description" 
1203 element it is possible to state the kind of a message, 
i.e. Request (Req) or Response (lisp) and what negotiation 
mode should be used (push, pull, push-pull) . 

10 

Fig. 13 illustrates the general structure of the „qosdef" 
element 1300. However, there is a constraint on the usage of 
the legal child elements, depending on the value of the 
„name" attribute of the qosdef element 1300. There are two 
15 possible values, ^capabilities" and ^contracts". Depending on 
that, the „qosdef" section 1300 either specifies capabilities 
of a peer or, in the case of contracts, defines validated 
contracts that have been validated by entities using the 
E2ENP UA 128. 

20 

- Specifying Capabilities: In case the „name" attribute's 
value of the „qosdef " element 1300 is capabilities", the 
valid child elements are „audio : codec" 1301, „video : codec" 
1302, and „rtp:pt" 1303. The respective codec elements rep- 
25 resent system capabilities of the peer in terms of audio 
and video codecs and their configuration. By using the 
„rtp:pt" 1303 element, it is possible to specify a desired 
RTP payload format for the given capabilities. 

30 - Specifying Contracts: In this case, the attribute value of 
the „name" element of the qosdef element 1300 has to be 
^contracts". Then, the valid child elements are „policy" 
1304, „audio" 1305, and „video" 1306. The „policy" element 
has to appear exactly once. It specifies the usage for ne- 

35 gotiating the resource management policies to enforce. It 
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is possible to use a policy to optimize one or several as- 
pects of system behavior, such as optimization of memory 
usage , CPU load, network traffic or power consumption. In 
order to achieve more flexibility, these atomic aspects can 

5 be combined by using predicates. The elements following the 
„policy M 1304 element can be one or many „audio" 1305, 
„video" 1306, „data" 1308, and „control" 1307 elements. 
These elements describe the QoS Contracts for the respec- 
tive data streams. By using the „rtp:map M 1309 element it 

10 is possible to define a mapping between an application 
level QoS Contract and a specific RTP payload format. 

Fig. 14 illustrates the general structure of the „qoscfg M 
element 1400. This section allows defining adaptation paths 

15 (AP) as well as QoS correlation and time synchronization con- 
straints at various levels of abstraction, starting from 
stream-level QoS Contracts. Each level of abstraction is 
identified by the attribute „name" of this section. Possible 
values include „stream x> , „stream-group M , „session", and 

20 ^application^ . Thus, the definition of adaptation paths is 

possible at different levels, including stream-level adapta- ■ 
tion paths as well as higher-level APs . The „context M 1401 
elements define possible associations of the given streams, 
thus allowing to define time-synchronization and/or QoS cor- 

25 relation constraints. As such, the „context" 1401 elements 
basically describe high-level QoS Contracts. 

In the following subsection, a brief overview of the Parser 
a API lOld shall be given. 

30 

The Parser API lOld provides primitives, which can be used to 
parse a description in some transport representation and gen- 
erate an object representation according to IF2. In order to 
be able to loosely couple the E2ENP UA 128 and the Parser 
35 112, this object representation is abstracted in such a way 
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that it is expressed as a. java. lang. Object. As already 
pointed out, the only requirement for the transport represen- 
tation is that it implements the java.io.Serializable inter- 
face. This can be interpreted in the sense that the transport 
representation is un-typed, thereby providing much flexibil- 
ity regarding what this representation can actually look 
like. 



The transport representation may contain references to exter- 
nal, previously defined entities. These references are left 
untouched and unresolved by the Parser 112. This issue is 
handled later in the E2ENP UA 128 or higher layer entities. 

The Parser API lOld provides one primitive for each message 
type to be passed. Like this, the message types are repre- 
sented implicitly and do not need to be considered in the ob- 
ject model. For each message type, the Parser 112 offers one 
primitive to parse the offer and the answer of the respective 
message type. Therefore, the general pattern depicted in Fig. 
15 for the Parser API lOld primitives is 

Object par seXXX(Ser ializable input) . 

Thereby, „XXX« denotes a placeholder for the names of primi- 
tives like NegOffer or PreNegAnswer, etc. (see the API defi- 
nition below for more details) . 

In addition to these general parsing methods, the Parser API 
lOld provides some specialized primitives intended to navi- 
gate through the content wrapped in the serialized represen- 
tation. These primitives can be used by clients to access 
specific information or data on an abstract level, independ- 
ent from the actual representation. Thus, if the representa- 
tion changes due to future protocol enhancements, the clients 
which use older versions of the representation are not af- 
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fected by the new changes since the information access, meth- 
ods do not change . 

As the actual carrier protocol should be exchangeable, there 
is a need for providing functionality to exchange the actual 
Parser 112 implementation as well. As described above, this 
mechanism has to be the same for the Parser 112 implementa- 
tion and for the carrier protocol. 

Therefore, a ParserFactory API is defined which provides 
primitives to create an actual Parser 112 implementation in- 
stance (factory 118 depicted in Fig. 1 shows an implementa- 
tion of such a ParserFactory) . Additionally, it is possible 
to register new actual Parser 112 implementations ■ for any 
given carrier protocol. 

The communication between the E2ENP UA 110 and the Parser 112 
could be asynchronous, e.g. implemented by an active request 
interface and a passive confirmation interface. However, this 
option is not appropriate for the underlying design, because 
some gain in performance and flexibility is opposed by much 
more complicated state models for the FSMs 106 of . the E2ENP. 
One consequence of this decision is that the E2ENP UA 128 and 
the Parser 112 (and also the Factory 114) communicate syn- 
chronously and thus have to share a common address space, 
which in most circumstances is a reasonable assumption. 

Another consequence of this decision is that the Parser 112 
(and also the Factory 114) have to be designed as thread- 
safe, re-entrant libraries. 

The object representation, generated during the parsing and 
passed as a result back to the calling E2ENP UA 128, is de^ 
scribed very abstractly by just using the java. lang .Object 
class, in order to provide loose coupling of the Parser 112 
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and the E2ENP UA 128. The actual classes implementing the 
Parser 112 for a given transport representation and a given 
object model, used in the E2ENP UA 128, have to be fitted to- 
gether by configuration. 

The actual Parser and Factory implementations 112 and 114, 
respectively, have to agree on a common format for the trans- 
port representation. The definition of these formats is im- 
plementation-specific and corresponds to the actual Parser 
112 and Factory 114 components, even though the usage of ex- 
isting standards is encouraged and envisioned. Therefore, a 
format has been defined, which is compatible to the baseline 
SDPng definition. 

The registration functionality offered by the ParserFactory 
API can be handled in different ways. However, this is up to 
the actual ParserFactory 112 implementation. Some options 
what can be done with registration are: 

♦ Registrations may be stored permanently to survive multi- 
, pie application life cycles. 

♦ Registrations may be made public for the use of other ap- 
plications 130, which also implies permanent storage. 

♦ Registrations may only be stored in a transient way for the 
current application life cycle. 

Applications 130 may check if they have instantiated a match- 
ing pair of Parser 112 and Factory 114 by calling the respec- 
tive getType() methods of these instances and comparing the 
returned values for equality. The usage of a non-matching 
pair of Parser 112 and Factory 114 by an application 130 may 
result in unpredictable results and undefined or even errone- 
ous behavior. 
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In the following, the dependencies shall briefly be summa- 
rized. 

♦ IF2 Object Model: This is only an implicit dependency that 
5 actual implementations of the Parser 112 have to fulfill. 

In general, this dependency is removed by the fact that 
the Parser 112 simply creates java.lang. Object instances. 
In a specifically configured system however, which will 
actually be created, instances of the specific object 
10 model classes are used in the E2ENP UA 128. 

♦ Transport Representation: Similar to the dependency above, 
an actual Parser 112 of course needs a well-defined struc- 
ture of what it has to create. Thus, it depends on the re- 

15 spective definition of the transport representation. But 

in general, by abstractly describing the transport repre- 
sentation using j ava . io . Serializable, this dependency is 
removed from the design. 

20 The primitives to be implemented by the Parser API lOld can 
be taken from Tab. 7. By contrast, the primitives to be im- . 
plemented for generating a specific Parser 112 are listed in 
Tab . 8 . 

25 The ParserFactory API is realized by the class E2ENPContent- 
HandlerFactory in the package or g. mind. e2enp. content, also 
referred to as parser-factory implementation. It is designed • 
as a singleton instance, so that all its clients can use reg- 
istrations made earlier. Currently, the singleton instance 

30 created is a default implementation, but for future releases 
it is planned to provide a configurable approach (based on 
specific system properties) to determine the class to be used 
for the singleton instance. Methods provided by the E2ENP- 
ContentHandlerFactory class are depicted in Tab. 11. 



35 
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In. the following subsection, the implementation of the Parser 
112 needed for an XML-based transport representation shall 
briefly be described. Thereby, a possible Parser 112 imple- 
mentation for the XML-based transport representation is pro- 
posed. Fig. 17 describes the general structure of a Document 
Object Model (DOM) tree, modeled as a class DocumentTree 
1702, which aggregates one DocumentNode 1704 and can be in- 
terpreted as the document root element. Each DocumentNode 
1704 in turn aggregates between 0 and N children, thus recur- 
sively describing the tree structure. 

The Parser 112 for this representation can be implemented by 
using the .^visitor design pattern" as described in [Gam]. The 
structural overview, is given in Fig. 18. Thereby, a generic 
Parser 112 visitor class pVisitor 1808 is defined to use> or 
to be precise visit, 1 to N DOMNodes 1806. In order to handle 
derived DOMNodes for each specially derived DOMNode- subclass, 
a specialized visitor is defined. (Even if the „visitor. pat- 
tern" is. intended for handling, only subclasses, this concept 
can easily be extended in such a way that different element . 
nodes are interpreted as categories of their own.). 

In the following, the Application Programming Interface (API) 
applied to the Factory 114 shall briefly be described. 

The Factory API lOle provides primitives which can be used to 
create a transport representation for a given object repre- 
sentation according to IF2. The loose coupling of the E2ENP 
UA 128 and the Factory 114 is realized via the abstraction of 
the object representation (passing through the Factory inter- 
face lOle) as a java.lang. Object. As already pointed out, the 
only requirement for the transport representation is that it 
implements the java.io. Serial! zable interface. Therefore, the 
primitives defined by this API all return 
„ j ava . io . Serializable" ob j ect s . 
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The object description may contain references to external , 
previously defined entities. These references are not handled 
or dereferenced by the Factory methods , they are just used. 

5 

Like the Parser 112, the Factory API lOle provides one primi- 
tive for each message type to be passed. Like this, the« mes- 
sage types are represented implicitly and do not need to be . 
considered in the object model. The general pattern for the 
10 Factory API primitives as depicted in Fig. 19 is: 

Serializable cr eat eXXX (Object input) 

Thereby, „XXX" denotes a placeholder for the names of primi- 
15 tives like NegOffer or PreNegAnswer, etc. (see the- API defi- 
nition below for more details) . 

Since the actual carrier protocol should be exchangeable, 
there is a need to provide a functionality to make the actual 

20 Factory 114 implementation exchangeable as well. As described* 
above, this mechanism has to be the same for the Factory 114 
implementation and for the carrier protocol. -Therefore,, a 
FactoryFactory API is defined which provides primitives to 
create an actual Factory 114 implementation instance. 

25 (factory 120 in Fig. 1 shows an implementation of such a Fac- 
toryFactory.) Additionally, it is possible to register new 
actual Factory 114 implementations for any given carrier pro- 
tocol in order to illustrate how the Factory API lOle and the 
Parser API lOld share a common transport representation syn- 

30 tax . 

Coinmunication between the E2ENP UA 128 and the Factory 114 
could be asynchronous, e.g. implemented by an active request 
interface and a passive confirmation interface. This option 
35 is not used in the scope of the underlying invention because 
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some gain in performance and flexibility is opposed by much 
more complicated state models for the FSMs 106 of the E2ENP. 
One consequence of this decision is that the E2ENP UA 128 and 
the Factory 114 (also .the Parser 112) communicate synchro- 
5 nously and thus have to share a common address space, which 
in most circumstances is a reasonable assumption. 

Another consequence of this decision is that the Factory 114 
(and also the Parser 112) have to be designed as thread-safe, 
10 re-entrant libraries. 

In order to provide loose coupling of the Factory 114 and the 
E2ENP UA 128, the transport representation, generated by the 
Factory 114 and passed back to the calling E2ENP UA 128 as a 

15 result, is abstractly described by using the 

java.io.Serializable class. Similarly, the java.lang. Object 
class abstractly describes the inputs of the Factory 114 
primitives. Thus, the actual classes implementing a Factory 
114 for a given transport representation and a given object 

20 model used in. the E2ENP UA 128 have to be fitted together by 
configuration. 

The actual Parser 112 and Factory 114 implementations have to 
agree on a common format for the transport representation. 
25 The definition of these formats is implementation-specific 

and corresponds to the actual Parser 112 and Factory 114 com- 
ponents, even though the usage of existing standards is en- 
couraged and envisioned. Therefore, a format is proposed 
which is compatible to the. baseline SDPng definition. 

30 

The registration functionality offered by the FactoryFactory 
120 can be handled in different ways. Some options for regis- 
trations include but are not limited to: 
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+ Registrations may be stored permanently to survive multi- . 
pie application life, cycles. 

♦ Registrations may be made public for the use of other ap- 
plications 130, which also implies permanent storage. 

5 ♦ Registrations may only be stored in a transient way for the 
current application life cycle. 

Applications 130 may check if they have instantiated a match- 
ing pair of Parser 112 and Factory 114 by calling the respec- 
10 tive getTypeO methods of these instances and comparing the 
returned values for equality. The usage of a non-matching 
pair of Parser 112 and Factory 114 by an application 130 may 
result in unpredictable results and undefined or even errone- 
ous behavior. 

15 

In the following, the dependencies shall briefly be summa- 
rized: 

♦ IF2 Object Model: This is only an implicit dependency that 
20 actual implementations of the Factory 114 have to fulfill. 

In general, this dependency is removed by the fact, that 
the Factory 114 simply expects j ava. lang. Object instances 
as input data. In a specifically configured system, how- 
ever, which actually will be passed in to the creation 
25 process, instances of the specific object model classes 

are used in the E2ENP UA 128. 

♦ Transport Representation: Similar to the dependency above, 
an actual Factory 114 of course needs a well-defined 

30 structure of what it has to create. Thus, it depends on 

the respective definition of the transport representation. 
But in general, by abstractly describing the transport 
representation using java. io . Serializable, this dependency 
is removed from the design. 
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The primitives specified by the Factory API 101e can be taken 
from Tab. 9. Additionally, the primitives to be implemented 
for generating a specific Factory 114 are listed in Tab. 10. 

The FactoryFactor.y API is realized by the class 
E2ENPContentHandler Factory in the package or g. mind. e2enp. con- 
tent, also referred to as factory- factory implementation. It 
is designed as a singleton instance, so that all its clients 
can use registrations made earlier. Currently, the singleton 
instance created is a default implementation, but for future 
releases it is planned to provide a configurable approach 
(e.g. based on specific system properties) to determine the 
class to be used for the singleton instance. Methods provided 
by the E2ENPContentHandlerFactory class can be taken from 
Tab. 11. 

In the following subsection, a possible Factory 114 imple- 
mentation for the XML-based transport representation shall be 
presented. 

Like the Parser 112, the Factory 114 implementation uses the 
„visitor design pattern" described in [Gam] . The structure is 
illustrated by Fig. 20. 

Again, a generic Factory 114 visitor class fVisitor 2002 is 
defined which visits 1 to N instances of ObjectGraphNode 2004 
classes. For each concrete subclass of ObjectGraphNode, a 
corresponding concrete visitor class is defined. 

In the following subsection, a brief overview of the SIP User 
Agent Generic API 101c (IF3) shall be given. 

Since the SIP User Agent Generic API 101c exposes the func- 
tionality of a generic SIP UA 110 to the E2ENP UA 128, the 
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main object of this API is to mask the actual implementation 
of the SIP UA 110 from the E2ENP UA FSM 106. The SIP User 
Agent Generic API 101c realizes the specification of such ge- 
neric API by defining a set of interfaces and complex data 
5 types exchanged through said API. Specific SIP UA 110 imple- 
mentations will be able to expose their native (eventually 
standard) APIs by means of specific Adapters, which shall map 
the SIP API native interfaces into the SIP UA Generic API 
101c, and vice versa. 

10 

The SIP UA Generic API 101c allows multiple users to simulta- 
neously access a given SIP UA 110 implementation (via multi- 
media applications 130 or middleware 130) for simultaneously 
establishing multiple SIP sessions. ■ 

15 

The SIP UA Generic API 101c also supports SIP Registrar im- 
plementations with the SIP signaling required by these enti- , 
ties. To this extent, it should be noted that the SIP UA Ge- ! 
neric API 101c is not designed to allow the simultaneous sup- : 

20 port of users' applications 130 and SIP Registrars on the 

same memory address space. With this design choice, SIP Reg- 
istrar implementations are thus forced to run as standalone 
server side entities, distinct from pure application 130 or 
middleware 130 entities (in the present context, the E2ENP UA 

25 FSM 106). Applications 130 and/or middleware 130 (in the pres- 
ent context, the E2ENP UA FSM 106) , and SIP Registrar imple- 
mentations are examples of Service Users. A SIP UA 110 im- 
plementation exposing the SIP UA Generic API 101c represents 
the Service Provider. 

30 

The SIP UA Generic API 101c has originally been designed to 
expose an API from a specific open source SIP UA 110 imple- 
mentation, the Mitre's JSIP v. 0.8 library 

(http://jsip.sourceforge.net/), wherein API support is quite 
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poor. The SIP UA Generic API 101c has been designed based on 
the following design principles: 

1. The definition of a set of primitives identifying vari- 
ous SIP procedures abstracted at a relatively high- 
level, thereby simplifying the E2ENP UA FSM 106 design. 
Of course, the granularity of the procedures exposed by 
the current version of the SIP UA Generic API 101c re- 
flects to a certain extent the capability of the JSIP 
implementation, other SIP UA 110 implementations might 
offer more or less capabilities, which would require 
respectively more or less logic embedded in the corre- 
sponding aforementioned Adapters. 

2. The' current version of the SIP UA Generic API. 101c fo- 
cuses only on the minimal set of features required for 
prototyping and testing the E2ENP UA 128. Therefore, 
the current version of SIP UA Generic API 101c is on 
purpose neither a complete SIP API specification nor 
meant to be standardized whatsoever. 

3. Primitives are classified into Request (Req) , vindica- 
tion (Ind), Response (Rsp), and Confirmation (Cfm) 
primitives according to the ISO/OSI model. Request 
(Req) and Response (Rsp) primitives are invoked by the 
client Service User of the IF3 101c, or by a SIP Regis- 
trar implementation in order to respectively initiate 
or respond to a particular message exchange. (In some 
cases the message exchange may involve a set of differ- 
ent messages being exchanged between peers, thanks to 
the abstraction offered by the given SIP UA 110 imple- 
mentation, whereas in other cases the message exchange 
is limited to the given message and its acknowledg- 
ment.) Indication (Ind) and Confirmation (Cfm) primi- 
tives are invoked by the Service Provider 110 to the 
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registered client-side of the Service User of the IF3 
101c in order to respectively indicate the arrival of a 
particular message or initiation of a particular mes- 
sage exchange or to confirm the conclusion of a given 
message exchange. The client-side of the Service User 
of the IF3 101c has to implement these primitives. To a 
Request (Req) primitive generated by the peer initiat- 
ing the given protocol message exchange corresponds an 
Indication (Ind) primitive at the target peer. To a Re- 
sponse (Rsp) primitive generated by the target peer, 
responding to the given protocol message exchange, cor- 
responds a Confirmation (Cfm) primitive at the initiat- 
ing peer. 

4. A simplified version of the ^observer design pattern^ 
as described in [Gam] (implemented in Java with a deri- 
vation of the Java Beans event model) offers the mecha- 
nism allowing the Service User to register (via a 
primitive called „Bind Request") for Indication (Ind) 
and/or Confirmation (Cfm) primitive callbacks. 

5. In order to allow supporting E2ENP piggybacking over 
SIP, each primitive allows passing a payload, e.g. SDP, : 
SDPng, or Multipurpose Internet Mail Extension (MIME) 
content . 

6. In order to allow dry- run tests of the E2ENP signaling 
logic without the support of a real SIP UA 110 imple- 
mentation and of SDP/SDPng Parsers 112 and/or Factories 
114, the primitives are designed to handle the payloads 
as generic objects (instead of plain objects represent- 
ing ASCII strings) that can be marshalled or demar- 
shalled when using Remote Procedure Call (RPC) mecha- 
nisms, like Java serialization or deserialization in 
combination with Java RMI. 
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7. Since Mitre's JSIP Version 0.8 implementation used for 
designing this SIP UA Generic API 101c lacks proper 
support of the SIP Expires header field, which is typi- 
cally manipulated by Service Users, an abstraction of 
this SIP header field has been created for handling any 
type of implementation of this field. This would be not 
necessary with other better SIP UA 110 implementa- 
tions, where the designer would have the choice to ei- 
ther change the SIP UA Generic API 101c (and therefore 
the.E2ENP UA-FSM.106 implementation) accordingly or 
provide an Adapter 126c mapping the Expires header 
field support of the given Service Provider (without 
changing the E2ENP UA FSM 106 implementation) . 

Further design choices are: 

• The E2ENP negotiation model described in [ReqSpec] is a 
key aspect of the E2ENP and a piece of information in- 
tended for being embedded into SDPng payload and ex- 
changed among peers on an end-to-end basis. For the sake 
of rapidly prototyping the E2ENP UA 128, a helper class 
named SipNegotiationModel 2216, representing the E2ENP 
negotiation model information, has provisionally been 
included into the SIP UA Generic API 101c. 

• Instead of uniquely identifying active sessions at ap- 
plication level by using the alphanumeric SIP Call Iden- 
tifier header field, the SIP UA Generic API 101c uses a 
numerical integer identifier, named connectionld. This 
choice was dictated by the following reasons: 



Service users can more easily handle lists 
with numerical identifiers rather than with alpha- 
numerical ones. 
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Should the E2ENP UA 128 use other protocols 
instead of SIP in future, having generic primi- 
tives and generic session identifiers would help 
partly reusing the existing E2ENP UA FSM 106 de- 
5 sign. 

The SIP UA 110 associates an unused value of the con- 
nections to the SIP Call Identifier header field of an 
incoming INVITE, OPTIONS, MESSAGE, or REGISTER method. 
10 By applying the same design principle, Service Users re- 

questing the transmission of any of those methods would 
obtain the connectionld value selected by the. Service- 
Provider in the Confirmation (Cfm) primitive associated 
with the original Request (Req) primitive • 

15 

Unfortunately, this solution is affected by to two prob 
lems : 



1. Without yet knowing the connectionld value as 
20 sociated with a given Request (Req) primitive, 

Service Users can not correlate a Confirmation 
(Cfm) primitive with its corresponding Request 
(Req) primitive. 

2. Before the arrival of a Confirmation (Cfm) 

25 primitive, intermediate messages (eventually indi- 

cating failure situations) might generate addi- 
tional primitives (e.g. a Connection Status Indica 
tion) , which would lead to the same correlation 
problem described in the previous point. 

30 

To solve these problems, the Service User must be in 
charge of selecting an unused connectionld value and 
force the SIP UA 110 associating such value with a 
proper SIP Call Identifier header field value. 



35 
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The set of connectionld values allocated by the Service 
Provider in case of incoming INVITE,. OPTIONS, MESSAGE, 
or REGISTER methods and by the Service User in case of 
outgoing INVITE, OPTIONS, MESSAGE, or REGISTER methods 
should be distinct, so that the processing of incoming 
and outgoing INVITE, OPTIONS, MESSAGE, or REGISTER meth- 
ods can simultaneously take place without interference. 

However, for the sake of simplicity, the SIP UA Generic 
API 101c has been designed with a centralized management 
of connectionld. values allocation, embedded into the 
Service Provider itself. Service users are yet in charge 
of allocating connectionld values for outgoing INVITE, 
OPTIONS, MESSAGE, or REGISTER methods, but the actual 
allocation is delegated to the Service Provider by in- 
voking the.getConnectionId() method exposed by Service 
Provider. This method can in no way be considered a ■■ 
primitive itself, since it directly returns a value (the 
selected connectionld value) : For instance, this would 
prevent implementing a loosely coupled interface, where 
primitives' are. exchanged between Service User and Serv- 
ice Provider via a (not RPC-like) message-based proto- 
col. In any case, Service Users and Service Providers 
can be designed without the centralized connectionld- 
value allocation management, and yet being compliant 
with the SIP UA Generic API 101c, by simply not using 
respectively implementing the getConnectionld ( ) method. 
As a special case, a connectionld can be reused in case 
of SIP re-INVITEs: in this case, a proper Boolean pa- 
rameter indicating whether this is a re- INVITE, shall be 
passed to the connectionReq primitive (see below) . 

Some primitives of the SIP UA Generic API 101c are SIP- 
specific: 



P 26921 EP and P 26922 EP 

61 



provisionalAck(Req|Ind|Rsp|Cfm) , which is used 
to implement the PRACK method, 

register (Req|Ind|Rsp|Cfm) , which is used to 
implement the REGISTER method, 
5 • options (Reql IndlRsplCfm) , which is used to im- 

plement the OPTIONS method, and 

message (Reql Ind|Rsp|Cfm) , which is used to im- 
plement the MESSAGE method. 

10 These primitives will eventually be mapped to more ge- 

neric ones in a future E2ENP UA 128 design review in or- 
der to transform the SIP UA Generic API 101c into a 
E2ENP Session Level Protocol API, which will be totally 
independent of the session-layer protocol actually used. 

15 

• The current version of the SIP UA Generic API 101c de- 
sign is only partially compliant with the latest working h 
(as of this writing) version of the SIP specification k 
described in [Rosl] . For instance, REFER, DO, NOTIFY, 
20 SUBSCRIBE methods and many other features have been i; ; 

omitted since they are not essential for testing the 
E2ENP concept. The BYE and CANCEL methods are supported 
by the same Disconnection primitive. 

25 Thereby, said E2ENP UA API 101b depends on the applied E2ENP 
UA FSM 106, concerning the implementation of the Indication 
(Ind) and Confirmation (Cfra) primitives and the Management 
component 102, which is used for configuring, controlling, 
and resetting the underlying SIP UA 110. 

30 

The SIP UA Generic API 101c has been designed using the ob- 
ject-oriented paradigm, and is thus hereby described by using 
the Unified Modeling Language (UML) . It is composed of a ba- 
sic package, the so-called org: :mind: :sip: rsipApi as depicted 
35 in Fig. 21. To this basic package belong the classes SipEnd- 
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User 2214 and SipExpiresHandling 2112. The SipEndUser class 
2214 represents a user accessing the SIP services offered by 
the SIP UA Generic API 101c. The SipExpiresHandling class 
generalizes the functionality for manipulating the SIP Ex- 
pires header field. The SipListener 2108 generalizes all the 
interfaces that Service Users shall implement for intercept- 
ing Indication (Ind) and/ or Confirmation (Cfm) primitives 
generated by the SIP UA 110. The SipProvider 2110 generalizes 
all the interfaces that the Service Provider shall support 
for implementing Request (Req) and Response (Rsp) primitives. 

Four sub-packages complete the SIP UA Generic API 101c speci- 
fication: one, the org: :mind: : sip: : sipApi: : time, deals with 
the SIP Expires header field abstraction, whereas the other 
three characterize different roles of the Service User: 

• org: : mind: : sip: :sipApi: :userAgent represents the applica- 
tion 130 / middleware 130 implementation (in the present 
context, the E2ENP UA FSM 10 6); 

• org: : mind: : sip: :sipApi: management represents the manage- 
ment entity 102; . . 

• org: :mind: : sip: :sipApi: : registrar represents the SIP Regis- 
trar implementation 2306. 

The org: :mind: :sip: :sipApi: :userAgent sub-package (cf. Fig. 
22) contains interfaces and classes specifying the part of 
the SIP UA Generic API 101c that the Service User of the IF3 
101c (in- the present context,- the E2ENP UA • FSM • 106) use for 
accessing the Service Provider. It consists of three major 
parts : 

1. Interfaces that Service Users of the IF3 101c shall im- 
plement for intercepting the Indication (Ind) and Con- 
firmation (Cfm) primitives generated by the Service 
Provider 110: 



P 26921 EP and P 26922 EP 

63 



- SipUserAgentListener 2202: common to both client 
and server side; a specialization of the 
org: : mind: : sip: rsipApi: : SipListener interface 2108. 

- SipUserAgentClientListener 2206: specific for the 
client side; a specialization of the SipUserAgent- 
Listener interface 2202. 

- SipUserAgentServerListener 2204: specific for the 
server side; a specialization of the SipUserAgent- 
Listener interface 2202. 

2. Classes bundling parameters for specific primitives 
(currently only the SipConnectionReq class 2208 for the 
Connection Request (Req) primitive, the SipRegistration- 
Req class 2218 for the Registration Request (Req) primi- 
tive, and the SipRegistrationCfm class 2220 for the Reg- 
istration Confirmation (Cfm) primitive) . Instances of 
these classes are passed as parameters of the given 
primitives to the modules implementing the primitives. 
This solution allows extending and/or changing API de- 
tails without disrupting the primitive signatures. 

3. Interfaces and classes specifying the API that the 
Service Provider shall support for being compatible with 
the SIP UA Generic API 101c. The SipUserAgentType inter- 
face 2210 specifies the set of Request (Req) and Re- 
sponse (Rsp) primitives that the underlying SIP UA. 110 
implementation shall support for being compatible with 
the SIP UA Generic API 101c. The SipUserAgentType inter- 
face 2210 is a specialization of the 

org: :mind: :sip: :sipApi: :SipProvider 

interface. The SipUserAgent class 2214 wraps amy given 
implementation of the aforementioned SipUserAgentType 
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interface 2210, by applying the „abstract factory" and 
„singleton"" design patterns as described in [Gam] . The 
^abstract factory" is defined by the SipUserAgentFactory 
interface 2212. The SipUserAgent class 2214 is designed 
to use a default implementation by using the deflmpl 
class attribute holding the fully qualified class name 
of the default implementation. Custom implementations of 
the aforementioned SipUserAgentType interface 2210 can 
be created by providing specific factory classes imple- 
menting the aforementioned SipUserAgentFactory interface 
2212. The SipUserAgent class 2214 provides a class 
- : method called setUserAgentFactory ( ) , which stores a sin- 
gleton instance of the given custom factory. 

Finally, this sub-package contains a class named SipNegotia- 
tionModel 2216* which represents the E2ENP negotiation model. 

The org: : mind: : sip: rsipApi: : registrar sub-package (cf. Fig. 
23) contains interfaces and classes specifying the part of 
the SIP UA Generic API 101c that SIP Registrar implementa- 
tions used for accessing : the Service Provider. It consists of 
three major parts: 

1. Interfaces that Service Users of the IF3 101c shall im- 
plement for intercepting the Indication (Ind) and Con- 
firmation (Gfm) primitives generated by the Service 
Provider: 

SipRegistrarListener 2302: common to both client 
and server side; a specialization of the 

org: :mind: :sip: :sipApi: :SipListener 



interface 2108. 
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2. Classes bundling parameters for specific primitives 
(currently only the SipRegistrationlnd class 2308 for 
the Registration Indication (Ind) primitive, and the 
SipRegistrationRsp class 2310 for the Registration Re- 
sponse (Rsp) primitive) . Instances of these classes are 
passed as parameters of the given primitives to the mod- 
ules implementing the primitives* This solution allows, 
extending and/or changing API details without disrupting 
the primitive signatures. 

3. Interfaces and classes specifying the API that the 
Service Provider 110 shall support for being compatible 
with the SIP UA Generic API 101c. The SipRegistrarType 
interface 2304 specifies the set of Request (Req) and 
Response (Rsp) primitives that the underlying SIP UA 110 
implementation shall support for being compatible with 
the SIP UA Generic API 101c. The SipRegistrarType inter- 
face 2304 is a specialization of the ^ 

org: :mind: :sip: rsipApi; : SipProvider 

interface 2110. The SipRegistrar class 2306 wraps any 
given implementation of the aforementioned SipRegistrar- 
Type interface 2304 by applying the ^abstract factory" 
and „singleton xx design patterns as described in [Gam] . 
The ^abstract factory" is defined by the SipRegistrar- 
Factory interface 2312. The SipRegistrar class 2306 is 
designed to use a default implementation by using the 
deflmpl class attribute holding the fully qualified 
class name of the default implementation. Custom imple- 
mentations of the aforementioned SipRegistrarType inter- 
face 2304 can be created by providing specific factory 
classes implementing the aforementioned SipRegistrarFac- 
tory interface 2312. The SipRegistrar class 2306 pro- 
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vides a class method called setRegistrarFactory ( ) , which 
stores a singleton instance of the given custom factory. 

The org: : mind: : sip: rsipApi: :management sub-package (cf. Fig. 
24) contains interfaces and classes specifying the part of 
the SIP UA Generic API 101c applied to the management entity 
102 for configuring and controlling the Service Provider. It 
consists of three major parts: 

1. Interfaces that Service Users shall implement for inter- 
cepting the Indication <Ind) and Confirmation (Cfm) 
primitives generated by the Service Provider: 

SipManagementListener . 

2. Classes bundling parameters for specific, primitives 
(currently only the SipConf igurationReq class; 2406 for 
the Configuration Request (Req) primitive) . Instances of 
these classes are passed as parameters of the given 
primitives to the modules implementing the primitives. 
This solution allows extending and/or changing API de- 
tails without disrupting the primitive signatures. 

3. An interface specifying the API that the Service Pro- 
vider shall support for being compatible with the SIP UA 
Generic API 101c. The SipManager interface 2404 speci- 
fies the set of Request (Req) and Response (Rsp) primi- 
tives that the underlying SIP UA implementation shall 
support for being compatible with the SIP UA Generic API 
101c. 
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The org: :mind: : sip: rsipApi: : time sub-package (cf. Fig. 25) 
contains interfaces and classes specifying the part of the 
SIP UA Generic API 101c that allow Service Users manipulating 
the SIP Expires header field. It consists of two major parts: 

1 . Interfaces and classes specifying the API that the 
Service Provider shall support for being compatible 
with the SIP UA Generic API 101c. The SipExpiresType 
interface 2502 specifies the set of SIP Expires header 
field manipulation operations that the underlying SIP 
UA 110 implementation shall support for being compati- 
ble with the SIP UA Generic API 101c. The SipExpires 
class 2506 wraps any given implementation of the afore- 
mentioned SipExpiresType interface 2502 by applying the 
^abstract factory^ and „singleton" design patterns : as 
described in [Gam] . The ^abstract factory" is defined 
by the SipExpires Factory interface 2508. The SipExpires 
class 2506 is designed to use a default implementation 
by using the deflmpl class attribute holding the fully 
qualified class name of the default implementation. 
Custom implementations of the aforementioned SipEx- 
piresType interface 2502 can be created by providing 
specific factory classes implementing the aforemen- 
tioned SipExpiresFactory interface 2508. The- SipExpires 
class 2506 provides a class method called setSipEx- 
piresFactory () / which stores a singleton instance of 
the given custom factory. 

2. The SipParseException class 2504 represents the excep- 
tion thrown by the Service Provider whenever the pars- 
ing of the SIP Expires header field fails, due to mal- 
formed syntax. 
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In the following subsection, the procedures enabled by the 
SIP UA. Generic API 101c shall be described by using a set of 
UML Message Sequence Charts (MSCs) . 

Fig. 26 shows how the Service Provider 110 is configured, and 
how a Service User of the IF3 101c creates and binds as Serv- 
ice User its client and server sub-units with the Service 
Provider 110. Fig. 27 shows how a SIP session can be estab- 
lished through the SIP UA Generic API 101c according to the 
procedures described in [Rosl] . 

This procedure. starts with a connectionReq primitive invoked 
by a peer acting as calling party (or initiator) , triggers a 
message exchange, which terminates only when the peer acting 
as called party (or responder) after having initially re- 
ceived a connectionlnd primitive notifying the initiator's 
invitation to establish a SIP session, eventually accepts 
such invitation (after a number of negotiation and signaling 
steps), and replies with a connectionRsp primitive. 

The responder generates SIP-provisional responses through the 
connectionStatusReq primitive invocations, which map at ini- 
tiator's side to connectionstatuslnd primitive invocations. 
The initiator acknowledges provisional responses with the 
PRACK method, by using the ProvisionalAckReq/Cfm primitive, 
which corresponds at responder' s side to ProvisionalAck- 
Ind/Rsp primitive, respectively. 

This procedure ends with the initiator receiving a connec- 
tioncfm primitive and the responder receiving a connection- 
statuslnd primitive. The latter is due to the SIP three-way 
acknowledgment scheme described in [Rosl] . 

Two procedures in this MSC are assumed to be executed auto- 
matically by the Service Provider: The generation of the ,,100 
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Trying" provisional response at responded s side, and the 
generation of the final. ACK signal, at initiator's side. The 
latter can, however, be forced by the Service User itself via 
the connect ionStatusRsp primitive, but this means that the 
5 Service User must accordingly be configured not to generate 
the ACK signal automatically. 

Final SIP responses indicating other reasons than success are 
generated either automatically by the Service Provider or ex- 
10 plicitly by the responder's Service User via the connection- 
StatusReq primitive. These SIP responses are notified to the 
initiator's Service User via the connections tatuslnd primi- 
tive. 

15 Fig. 28 shows how the OPTIONS method is handled via the op- 
tionsReql Ind|Rsp|Cfm primitives. Fig. 29 shows how a SIP ses- 
sion can be released via the disconnectionReql Ind|Rsp| Cfm 
primitives. The MSC shows the case of BYE, but the same pro- 
cedure invoked during a connection establishment generates a 

20 CANCEL. 

In the following subsection, the Finite State Machine 106 
(FSM) applied to the E2ENP UA 128 shall briefly be described. 

25 The core of the E2ENP UA 128 is composed of a Finite State 
Machine 106 (FSM), which coordinates the overall functional- 
ity and implements a part of the aforementioned interfaces. 
More specifically, the FSM 10 6 implements the Service User 
part of the IF3, IF4 and IF5, and the Service Provider part 

30 of the IF1 and IF2. Furthermore, the E2ENP UA FSM 106 makes 
use of the Cache 104 described above. 

The FSM 106 is designed hierarchically as a StateChart. In 
the Root State (cf. Fig. 30), the FSM 106 handles session- 
35 terminating events, either associated with local or remote 
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users' decisions. Furthermore, the Root State handles pre- 
negotiation, lease renewal, negotiation as Of ferer /Answerer, 
re-negotiation, and session release processes. It should be 
noted that the term negotiation" process is used for indi- 
cating a multimedia session establishment, intertwined with 
resource reservation coordination and QoS negotiation, as de- 
scribed in [ReqSpec] . 

The role of the Offerer is taken by the peer who is initiat- 
ing a session establishment with QoS negotiation and resource 
reservation", but also by the peer who decides to initiate a 
re-negotiation: The role of the Answerer is always taken by 
the peer who is responding to an invitation to carry out a 
session establishment process with QoS negotiation and re- 
source reservation, but also by the peer who. decides to re- 
spond to. an invitation to carry out a re-negotiation. This 
means that a peer initially acting the Offerer role can later 
take either the Offerer or the Answerer role during a re- 
negotiation. And vice versa, a peer initially acting the An- 
swerer role can later take either the Offerer or the Answerer 
role during a re-negotiation. 

For the sake of simplicity, Fig. 30 does not detail the han- 
dling of primitives associated with IF1 (Management API); 
neither the internal interfaces with the FSM. factory 10 6 nor 
the Cache 104 are taken into account. 

The following subsections provide a detailed description of 
the mutex-related procedures shown in Fig. 30. 

Lower-level details of the negotiation process as Offerer/ 
Answerer are encapsulated in nested FSMs 10 6, respectively 
the NegOfferer sub-state (cf. Fig. 31) and the NegAnswerer 
sub-state (cf . Fig. 32) . 
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The NegOf ferer sub-state contains a nested FSM 106 capturing 
the logic handling the negotiation process, as seen from the 
Offerer perspective. The NegAnswerer sub-state contains a 
nested FSM 106 capturing the logic handling the negotiation 
5 process, as seen from the Answerer perspective. 

In order to guarantee consistency and avoid deadlocks during 
the combined reservation of local, peer, and network re- 
sources as described in [ReqSpec] , the FSMs. 106 nested in the 

10 NegOf ferer sub-state and in the NegAnswerer; sub-state use the 
system-wide „_JResvMtx" FSM 106 for accessing the reservation 
phase on a mutually exclusive basis, with respect to other 
• instances of the E2ENP UA FSM 106. The „_ResvMtx x> FSM 106 in- 
teracts with various instances of the E2ENP UA FSMs 106 via 

15 atomic local methods invocation (e.g. via any specific system 
call provided by the underlying Operating System) . 

The following subsections provide a detailed description of 
the mutex-related procedures shown in Fig. 31. 

20 

Lower-level details of the re-negotiation process as Offerer/ 
Answerer are encapsulated in nested FSMs 106, respectively 
the ReNegOf ferer sub-state (cf . Fig. 33) and the ReNegAn- 
swerer sub-state (cf . Fig. 34) . 

25 

- The ReNegOfferer sub-state contains a nested FSM 106 cap- 
turing the logic handling the re-negotiation process, as 
seen from the Offerer perspective. 

30 - The ReNegAnswerer sub-state contains a nested FSM 106 cap- 
turing the logic handling the re-negotiation process, as 
seen from the Answerer perspective. 

In order to guarantee consistency and avoid deadlocks during 
35 the combined reservation of local, peer, and network re- 
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sources as described in [ReqSpec], the FSMs 106 nested in the 
ReNegOfferer sub-state and in the ReNegAnswerer sub-state use 
the system-wide „JResvMtx" FSM 106 for accessing the reserva- 
tion phase on a mutually exclusive basis, with respect to 
other instances of the E2ENP UA FSM 106. The „_ResvMtx" FSM 
106 interacts with various instances of the E2ENP UA FSMs 106 
via atomic local methods invocation (e.g. via any specific 
system call provided by the underlying Operating System). 

The following subsections provide a detailed description of 
the mutex-related procedures shown in Fig. 33. 

This mechanism enforces a transaction-like processing of the 
resource reservation phase by enforcing various concurrent 
instances- of the E2ENP UA Service Users to mutually exclu- 
sively access such a phase, as described in [ReqSpec] . In. 
other words, the resource reservation mutex allows defining 
the phase between local admission . control and final network 
resource reservation as a critical section. Combined with the 
contention resolution policy, this mechanism also guarantees 
that no deadlock situation as described in [ReqSpec] might 
affect the E2ENP whatsoever. 

Concurrent E2ENP UA Service User instances try to seize the 
mutex via suspensive method calls. The Service User instance 
owning the mutex releases it via the signal call event. 

The „_ResvMtx" is associated with a priority queue for allow- 
ing multiple requests to seize the mutex in a coordinated 
manner, based on their priority (cf. Fig. 35) ... 

Any request is served immediately if the mutex is unlocked; 
otherwise, the request is queued. Requests with high priority 
are queued in front of requests with low priority. Requests 
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with the same priority, are queued in a „First-In-First-Out xx 
(FIFO) order . 

All requests to acquire the mutex are limited in time* Upon 
5 expiration of such a (configurable) time, the given E2ENP UA 
Service User instance pending on the mutex is resumed with a 
return value indicating failure. 

This design choice allows detecting (and thus preventing) 
10 starvation of concurrent E2ENP UA Service User instances . sus- 
pended on the mutex, which occurs when the Service User in- 
stance owning the mutex is misbehaving (or maybe blocked) . 
This is of most importance, especially in case the ill- 
behaved Service User instance are suspended on some other ap-. 
15 plication-specific mutex, semaphore or lock,, eventually, 
seized by one of the Service User instances queued on the 
„_ResvMtx" : In such an unfortunate situation, a dead lock 
would in fact inevitably occur. 

20 When the timer associated with each blocked request expires, ■ 
the priority of that request (specified in the parameter list 
of respectively the bookNegotiationReq or bookRenegotiation- 
Req primitives, cf . Tab. 1) should be higher than the prior- 
ity of the one for which the mutex was granted, the mutex 

25 would throw a signal event, congestionlnd, to the instance of 
the FSM 106 UA associated with the Service User instance own- 
ing the mutex. This event is caught by the E2ENP UA FSM 106 
Root state and mapped to a failurelnd primitive sent to the 
Service User instance owning the mutex. 

30 

According to application- specif ic policies, such Service User 
instance might react on such event by rolling-back the cur- 
rent status of its activities and starting a release opera- 
tion, which in turn would force the release of the mutex, as 
35 indicated in Fig. 30. Should however such Service User in- 
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stance act differently (either based on application-specific 
policies or because being blocked or just misbehaving) , the 
other instances would nevertheless be able to detect the pro- 
longed delay on acquiring the mutex (after a configured num- 
ber of failed attempts to invoke the get method success- 
fully) , thanks to the bookNegotiationCfm (or bookRenegotia- 
tionCfm in the re-negotiation case) primitives indicating a 
failure case (see Figs. 31 and 33, respectively). In such 
cases, the notified E2ENP UA Service User instances might in- 
voke the mediation of an application-specific arbitration 
unit.. To. manage all these exceptional cases/dead locks, the 
resetReq primitive can be. issued at any time to cancel the 
current given session and release the mutex, if necessary. 

A . key issue typically encountered when using mutex entities 
is the so-called priority inversion problem, which occurs 
whenever a task ^ owning the mutex has a lower priority than 
other tasks T k blocked on: the mutex, and more precisely when 
the gets pre-empted by a task T x with a priority greater 
than Tj but less than T k . 

Given the design choice of enforcing loosely coupled inter- 
faces to both the E2ENP UA Service Users and to the SIP UA 
110, the E2ENP UA 128 containing the „_ResvMtx" implementa- 
tion cannot directly enforce well-known protocols, e.g. the 
Priority Inheritance Protocol or the Priority Ceiling Proto- 
col. This is after all a consequence of designing the E2ENP 
UA 128 as a software component. 

However, if the E2ENP UA FSM 106 is designed to handle a 
thread-pool for processing concurrently multiple instances of 
the FSM 106, the priority inversion problem might be tackled 
at least on this level. In this connection, the enforcement 
of the Priority Inheritance Protocol allows to achieve a good 
performance in handling the aforementioned problem. To this 
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extent, the priority specified in the parameter list of the 
bookNegotiationReq primitive (or bookRenegotiationReq in the 
re-negotiation case, cf . Tab. 1) issued by each E2ENP UA 
Service User instance is assigned as priority of the thread 
5 serving that FSM 106 instance. The ^_ResvMtx^ shall therefore 
temporarily raise the priority of the thread associated with 
the FSM 106 instance owning the mutex to the priority of any 
blocked thread if the priority of the latter is greater than 
the one of the former. 

10 

The E2ENP UA 128 thus provides the tools for solving deadlock 
and priority inversion problems: However, this is up to the 
applications 130 or QoS Brokers 130 using such tools to guar- 
antee that those problems will never occur. 

15 

In the following subsection, the resource reservation coordi- 
nation process shall be described - 

The NegAnswerer (cf . Fig. 32) and ReNegAnswerer (cf . Fig. 34) 
20 sub-states each contain an instance of the same composite 
state, the WaitForCoordDone sub-state (cf. Fig. 36), whose 
nested FSM 106 captures the logic handling the coordination 
of resource reservation signaling required before the An- 
swerer is actually alerted and the Offerer informed corre- 
25 spondingly thereupon. 

The resource reservation coordination process is based on the 
mechanisms described in [Caml], with the following differ- 
ences : 

30 

1. The preconditions described in [Caml] can be mapped to 
the E2ENP „qosdef" section and its corresponding nego- 
tiation process described in [ReqSpec] . 

2. The E2ENP prescribes the synchronization of the reserva- 
35 tion processes between peers (the „confirm x> tag in 
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[Caml]) as always mandatory due to the ^Economy Princi- 
ple": This means that the end-to-end signaling of the 
^confirm" tag (or anything equivalent) is unnecessary 
and thus shall not be supported by any E2ENP implementa- 
tion. 

3. In case of no network resource reservation carried out 
by the Offerer, the Answerer shall determine this case 
by examining the preconditions sent by the Offerer, and 
correspondingly mark the state RemoteTokenAchieved as 
active in Fig. 36, so that the Answerer will be able to 
transparently deal with resource reservation coordina- 
tion. 

Impact on SIP implementation (e.g. the introduction of the 
status response and the new value ^preconditions" for the 
^Supported" header field of the OPTIONS method) are left for 
further study. 

An important aspect is that the E2ENP described in [ReqSpec] 
explicitly claims that the Economy Principle is always re- 
quired, including the concept described in [Caml] of allowing 
both end-to-end and segmented reservations. In the latter 
case, enforcing the Economy Principle might not always be de- 
sirable. There might in fact be situations where reservation 
can be well done locally on beforehand with no cost and/or 
major impact on session establishment. For instance, some us- 
ers might be attached to an intranet or wireless LAN, where 
network resource reservation might be free and starving other 
users might flexibly be handled. Therefore, the original 
E2ENP shall accommodate this case and rely on the applicabil- 
ity of the Economy Principle to allow the aforementioned 
case. 



It should be noted that the E2ENP does not imply that a di- 
rect interface to reservation entities is available: It is 
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to the applications. 130 or QoS Broker 130 to access those en- 
tities. If the latter wishes to execute a „pre-reservation" 
of network resources/ it might do that, but the E2ENP signal- 
ing would still give the right timing to the applications 130 
or QoS Broker 130, thereby informing it when the reservations 
at all sides have been accomplished according to the Economy 
Principle, e.g. which signal has reached the level of the de- 
sired QoS (even though best effort communications might well 
have been started on beforehand, if specified by the applica- 
tions 130 or QoS Broker 130, respectively) . 

For the sake of simplicity, the model depicted in Figs. 30 to 
3 6 only partially details the handling of unexpected events 
and error cases. Tab. 18 completes the description of said 
model by indicating the behavior expected in case any of such 
events or errors occur. 

A set of timers is defined to avoid that the E2ENP UA FSM 106 
gets stuck in a state waiting for an event from the Service 
User and/or the SIP UA 110. The treatment of timers for han- 
dling primitives across the E2ENP UA API 101b (T1-T22) does 
not prescribe the E2ENP UA FSM 106 taking autonomously cor- 
rective actions, except for a few cases (missing negotiation- 
Req in Root .NegOf f erer . WaitNegReq and renegotiationReq in 
Root.ReNegOfferer .WaitReNegReq) . The E2ENP UA FSM 106 simply 
notifies the misbehaving Service User about the detected 
problem via the failurelnd primitive upon which the Service 
User is supposed to clean up and send a releaseReq primitive 
to the E2ENP UA FSM 10 6. However, if this counteraction does 
not succeed, e.g. owing to massive problems at the Service 
User side, the E2ENP UA FSM 106 would detect this situation 
upon expiration of yet another timer: in this case, the E2ENP 
UA FSM 106 finally takes the decision to release the SIP con- 
nection and the overall E2ENP session. To manage all these 
exceptional cases/dead locks, the resetReq primitive can be 
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issued at any time to cancel the current given session and 
release the mutex, if necessary. 

However, the composite states Root .ReNegOf ferer, Root.Neg- 
Answerer, Root .ReNegOf ferer, Root . ReNegAnswerer may detect a 
later arrival of the missed primitive (eventually triggered 
by the invocation of the failurelnd primitive) by using each 
an History state (cf. Figs. 31, 32, 33, and 34). With this 
solution, the late primitive arrival would be caught in the 
right original state and processed correctly. This means that 
whenever the- aforementioned timers expire, the aforementioned 
composite states shall each take care of updating the history 
to point to the state where the timer expired. 

Should a SIP primitive fail, specific timers (T101-T106) 
would detect the failure at the Root .ReNegOf ferer, Root.Neg- 
Answerer, Root .ReNegOf ferer, Root . ReNegAnswerer composite 
states: In these cases, the same procedure as described above 
(based on the failurelnd primitive) shall be enforced. 

For the interface, similar approaches to the potential prob- 
lem of primitive failure have to be pursued by means of the 
management entity 102, which is. however not detailed in this 
section.' 

For properly implementing the E2ENP concept, the dual seizure 
event (peers simultaneously initiating a negotiation session 
with each other) shall be properly detected and handled in 
order to allow that consistency is guaranteed and that any 
correlation between outgoing and incoming invitations is en- 
forced. 

The former issue can be addressed by using a mutex for regu- 
lating the access to the Economy Principle phase on a system- 
wide basis (the „_ResvMtx" described in the sections above) . 
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For enforcing any correlation, some additional support is re- 
quired instead. Two possible approaches are envisioned: 

a. to use the push-pull model for allowing both Offerer and 
5 Answerer having a chance to send an offer to the peer, 

thus avoiding the possibility of simultaneously generating 
two negotiations in both directions for the same session; 

b. to treat the attempt of handling negotiations simultane- 
10 ously in both direction as a double seizure, which re- 
quires a contention resolution policy to be enforced (e.g. 
wait on a random timer on both sides, and then retry) • 
But this would mean that both peers should use the same 
external representation of the session ID in order to be 

15 able to detect a double seizure. Otherwise, each of the 

two UAs would treat the outgoing and incoming negotiations 
as independent sessions. This would be similar to the case 
peer A invited peer B to e.g. a videoconf erence, while 
peer B would invite peer A to another videoconf erence, 

20 whereas the videoconf erence could actually be the same. 

The way E2ENP defines the external representation of the 
session ID described in [ReqSpec] allows the two peers 
creating only distinct IDs. Therefore, the E2ENP-speci- 
fication per se does not allow detecting double seizures 

25 at all. 

A reasonable solution to this issue is to enforce the push- 
pull model (first approach) as much as possible and to in- 
clude in the re-negotiation phase the possibility to allow 
30 the Answerer to send an offer to the Offerer at a later time 
(i.e. after the first negotiation has been entirely com- 
pleted) . 



35 



This means that the E2ENP shall allow the Offerer and/or any 
Answerer to negotiate with the other Answerers and/or the Of- 
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ferer upgraded or new information for establishing QoS-aware 
multimedia sessions. This means that re-negotiations can be 
subdivided in two classes: 

• planned re-negotiations as described originally in 
[ReqSpec] , 

• unplanned re-negotiations, which are used for negotiat- 
ing upgraded or new information during the lifetime of a 
session. 

An explicit Boolean parameter in the pre-negotiation primi- 
tive indicates whiclr of the two classes the given primitive 
should be used for. Of course, the semantics could.be in- 
ferred from the information passed, which would be different 
in the two cases, but the Boolean parameter is a good trade- 
off between having this distinction, which has explicitly 
been made for improving performance, and the need to keep the 
E2ENP UA API 101b and FSM 106 simple by avoiding additional 
primitives. 

However, applying the aforementioned solution might not suf- 
fice in the general case since a. non— E2ENP compliant SIP UA 
110 might interfere with E2ENP compliant peers, or one of the 
participants might try to invite some of the other partici- 
pants to a parallel multimedia session and use the E2ENP to 
accomplish this. 

SIP loosely tackles the dual seizure problem by suggesting a 
contention resolution policy (indicated as a „MAY" require- 
ment in [Rosl]), whereby peers abort the invitation by reply- 
ing with an Internal Server Error response, carrying a Retry- 
After SIP header field set to the time after which the remote 
peer should retry. 



r ^oa^i EP and P 26922 jsf 

81 



The dual seizure detection is accomplished by matching all 
messages between each given couple of users, via the To- and 
From-SIP header fields. This means if a first user is using 
UA A and sends an INVITE to a second user on UA B, and vice 
versa, both users can detect the dual seizure by using the 
couple (To, From) as a unigue identifier for correlating . the 
two INVITES. 

But this is not exactly the way E2ENP identifies sessions. If 
users are engaged in two independent videoconf erences, the 
E2ENP can actually distinguish such cases by using the ses- 
sion ID described in [RegSpec] . In any case, the biggest • is- 
sue is what would the SIP UA 110 do in such a case, given 
that, the aforementioned SIP reguirement is a MAY retirement 
and thus not necessarily supported by all SIP implementa- 
tions . 

One has to assume that the aforementioned policy may be im- 
plemented: Thereby, the E2ENP UA 128 would not notice the 
dual seizure, except for an indication of an unsuccessful ne- 
gotiation or re-negotiation phase. But one could also get 
into dual seizure troubles if the contention resolution pol- 
icy is not supported by the underlying SIP UA 110 implementa- 
tion. 



To tackle the latter case, the Cache 104 should store for 
each of its entries also the (E2ENPFromAddress, E2ENPTo- 
Address) couple associated with the outgoing INVITE and use 
this information for correlating an incoming INVITE with a 
pending outgoing INVITE registered in the Cache 104, thus de- 
tecting the double seizure case: This would then trigger a 
contention resolution policy. This means that every incoming 
INVITE received after sending an INVITE should be checked by 
searching the Cache 104 with the aid of a secondary key, us- 
ing the (From, To) couple. Although this is an extra effort 
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it is only limited to the specific case of receiving an 
INVITE after having sent one. ... 

As an alternative to the contention resolution policy sug- 
gested by [Rosl], which is eventually implemented by the un- 
derlying SIP UA 110, the E2ENP UA 128 shall support a more 
general policy, which is also applicable to complex scenarios 
like one-to-many or many-to-many described in [ReqSpec] . 

Whenever initiating a negotiation or pre-negotiation phase, 
the E2ENP UA 128 should not only include the session ID de- 
scribed in [ReqSpec] in the offer sent within the INVITE but 
also a hash thereof which takes the IP address of the comput- 
ing unit where the E2ENP UA 128 is active into account and a 
time, stamp. This hash might also be signed digitally in order 
to improve security aspects [ReqSpec] . The hash will be used 
as a substitute for the session ID in any subsequent SIP mes- 
sage. Should a dual seizure occur, the E2ENP would detect it 
by using the aforementioned (From, To) couple. Thereby, said 
contention resolution policy would be applied as follows: 

♦ If the two peers are not already involved in multimedia 
sessions (which means no entry in the Cache 104 for a 
given local peer), each peer would compare the hash it 
generated with the one received from the peer. The peer 
with the biggest value is automatically chosen as Offerer 
and thus proceeds with the pre-negotiation or negotiation 
phase as .such, whereas the other peer^ the „loser A \ auto- 
matically moves to the Answerer mode, according to the 
following MSC: 
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Application (130) — E2ENP UA (128) 

negotiationReq > 

< abort I nd 

< negotiationlnd 

negotiationRsp > 



If the two peers are already involved in multimedia ses- 
sions (which means an entry in the Cache 104 for the given 
(From, To) couple), the „bully" process described in the 
previous point could be applied as well. The peer whose 
request is rejected could apply an unplanned re-negotia- 
tion after the winner of the „bully" process has completed 
its negotiation. An example for this case is the . simulta- 
neous detection and re-negotiation reaction of the in- 
volved peers to a QoS violation. 



♦ Since the generated session ID contains also a randomly 
generated number (together with the IP, port, etc. infor- 
mation) for the identification, it is not to be expected 
that some of the peers would always be „winners" and some 
always „losers". 

Finally, the aforementioned contention resolution process 
also applies to the case of a negotiation procedure colliding 
with a pre-negotiation procedure or even a lease-renewed pro- 
cedure as well as for the collision of a pre-negotiation pro- 
cedure with a lease-renewed procedure. 

The model described in the previous subsections represents 
the static definition of the E2ENP UA FSM 106. At runtime, 
the E2ENP UA 128 shall associate a specific E2ENP session' 
with an object representing it. This object - the Session - 
shall contain any information related with the given E2ENP 
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instance: most notably, a pointer to the current state and 
the instance of all the condition variables defined in the 
model above. 

A thread of execution shall dynamically be associated with 
each of these Session objects: either created on demand, or - 
better - picked up from a thread-pool (potentially with lazy 
initialization) . 

♦ This version of the 5 E2ENP is based on the SIP protocol 
specification described in [Rosl] . If at later time an- 
other session level protocol or a more generic approach is 
chosen, the FSM 106 should be reworked in order to mask 
the corresponding changes from applications 130 or QoS 
Brokers 130 j thanks to the E2ENP UA API 101b abstraction. 

' This means that the interaction of the FSM 106 with the 
E2ENP UA API 101b Service User is a design-invariant. 

♦ The use of the SIP MESSAGE method is tentatively indicated 
in Fig. 30 . Alternatively, the SIP OPTIONS method could be 
used. In the scope of the underlying invention, only the 

: latter is exposed by the SIP UA Generic API 101c since the 
use of the former for implementing the FSM 106 model de- 
scribed below is still being' investigated. 

♦ In order to avoid that entities interfacing with the E2ENP 
UA 128 (e.g. the E2ENP UA 128 Service Users, the SIP UA 
110, and E2ENP management entities 102) directly invoke 
E2ENP UA 128 incoming primitives in response to E2ENP UA 
128 outgoing primitives before the E2ENP UA 128 has ever 
had a chance to reach a stable state configuration, the 
E2ENP UA 128 is by design always loosely coupled with the 
aforementioned external entities. Another reason for this 
design choice is the possibility that otherwise there 
would be a non-null probability that the entities inter- 
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facing with the E2ENP UA 128 might block indefinitely a 
E2ENP UA thread. 

This means that the E2ENP UA 128 shall enforce one incom- 
ing message queue for the whole E2ENP UA FSM 106 as well 
as an outgoing message queue for each of the interfaces 
IF1, IF2, and IF3. The reason for the latter queues is due 
to the fact that the E2ENP UA 128 , which is a software 
component, can not make any assumption on the way applica- 
tions 130 would handle primitives thrown by the UA. 

This approach is not necessary for IF4 and IF5 since the 
Parser 112 and the Factory 114 are designed as thread- 
safe, re-entrant libraries accessed by the E2ENP UA FSM 
106 via synchronous interfaces. 

Concurrent instances of the E2ENP UA FSM 106 are handled 
with the aid of a thread-pool. 

The E2ENP UA FSM 106 depends on the following compo- 
nents: 

the E2ENP UA API 101b, exposing the E2ENP functionality as 
implemented by the FSM 106, 

the Parser API lOld, used for accessing services dealing 
with the parsing of session descriptions contained in re- 
ceived SIP messages, 

the Factory API lOle, used for accessing services dealing 
with the creation of session descriptions to be inserted 
in outgoing SIP messages, 

the SIP UA Generic API 101c, used for accessing SIP serv- 
ices, 
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♦ the E2ENP Management API 101a, used for accessing services 
dealing with the overall E2ENP UA 128 management function- 
ality/ and 

♦ the Cache 104, used for storing and correlating identifi- 
ers of a given session. 

The E2ENP UA FSM model is described in Figs. 30, 31, 32, 34, 
and 36 in terms of UML State Charts and can be implemented by 
using various well-known design patterns. In any case, as in- 
dicated in Fig. 1, the FSMs 106 are associated at runtime 
with instances of the applied framework or design pattern to 
implement the model. Each instance is associated with a, spe- 
cific SIP phase [ReqSpec] , i.e. pre-negotiation, lease re- 
newal, or negotiation. Re-negotiations run on the same in- 
stance as the underlying session established with the corre- 
sponding negotiation. 

In order to handle the life cycle of an FSM 106 instance 

(creation, activation, deactivation, and destruction), an FSM 
instance factory 106 (see Fig. 1) is envisioned. This should 
be a singleton object creating instances of the FSM 106 ei- 
ther upon invocation of specific E2ENP UA API 101b primitives 

(negotiationReq, prenegotiationReq, renewLeaseReq) or upon 
invocation of specific SIP UA Generic API 101c primitives 

(connectionlnd, optionslnd, messagelnd) . 

Fig. 37 depicts the MSC for a simple pre-negotiation sce- 
nario, ^wherein the correlation between the E2ENP UA API 101b 
and the SIP UA Generic API 101c via the E2ENP UA FSM 106 is 
highlighted. 

Fig. 38 depicts the MSC for a simple session establishment 
scenario, wherein the correlation between the E2ENP UA API 
101b and the SIP UA Generic API 101c via the E2ENP UA FSM 106 
is highlighted. In the presented scenario, the confirmation 
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of resource reservation completion from the Offerer side ar- 
rives before the same happens at Answerer side. Likewise, it 
is assumed that the resource reservation process succeeds in 
reserving exactly the amount of the originally requested re- 



source. 



In the following subsection, the E2ENP UA factory 108 shall 
briefly be described. 

The E2ENP UA factory 108 is a management functionality mod- 
eled according to the ^abstract factory" design pattern de- 
scribed in [Gam] for instantiating a specific E2ENP UA 128 
implementation using an implementation- independent interface 

This entity handles the instantiation of all the classes de- 
scribed in the previous sections required to create an in- 
stance of the E2ENP UA 128. More specifically, the E2ENP UA 
factory 108 creates the following entities: 

♦ an E2ENP UA FSM factory, which in turn creates the E2ENP 
UA FSM static structure, 

♦ the FactoryFactory 120, which in turn creates the E2ENP 
Factory 114, 

♦ the ParserFactory 118, which in turn creates the-E2ENP 
Parser 112, and 

♦ the Cache 104. 

Thereby, said E2ENP UA factory 108 depends on the following 
components : 



♦ the application 130 and/or middleware 130, which may di- 
rectly call the E2ENP UA factory 108, alternatively a man- 
agement entity 102. 
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♦ the E2ENP UA FSM 106, whose factory is created by the 
given concrete E2ENP UA factory implementation* 

♦ the Factory 114 and Parser 112, whose factories are cre- 
ated by the given concrete E2ENP UA factory implementa- 

5 tion. 

♦ the Cache 104, which is created by the given concrete 
E2ENP UA factory implementation. 

The E2ENP UA factory 10'8 has been designed by using the ob- 
10 ject-oriented paradigm. Thus, it is hereby described by using 
the Unified Modeling Language (UML) . 

In the following, the E2ENP object configuration parameters 
shall briefly be summarized. 

15 

The E2ENP UA 128 and its sub- components (FSM 106, Parser 112, 
Factory 114, Cache 104) are configurable elements. The ini- 
tial configuration should consider the specific features of 
the peer using the E2ENP UA 128. 

20 

The E2ENP UA-128 should be initialized with the following pa- 
rameters : • 

♦ The E2ENP UA FSMs 106 are initiated with specific time- 

25 outs for the crucial states, where prompt decisions about 

the performance should be taken. The length- of the time- 
outs depends on the specific underlying protocol of the 
E2ENP UA 128 and on the performance features of the re- 
spective peer. The time-outs of the different devices and 

30 networks may vary with a certain extent. The implementers 

should consider these variations by defining the time- 
outs . 

♦ The Cache 104 does not need any configuration parameters 
and is initiated by the E2ENP UA 128. 
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♦ The Parser 112 and the Factory 114 are respectively con- 
figured with the used underlying protocol type and their 
respective class name. They are initiated by means of the 
E2ENP UA 128. 

5 

The configuration of the E2ENP UA 128 and its respective com- 
ponents can be performed either manually with: the aid of a 
Graphical User Interface (GUI) or can be preset with configu- 
ration parameters read from a configuration file. 

10 

Concerning the E2ENP UA FSM 106, the following parameters . are 
conf igurable : 

♦ Thread-pool configuration parameters: 

15 

* Maximum number of threads in the E2ENP thread-pool. 

* Selector indicating whether the pool should have a lazy 
initialization (i.e. threads are created only when re- 
quired) . 

20 

• Selector indicating whether thread-pool optimization 
is required (only when lazy initialization is en- 
forced) . For optimization reasons, the pool might be 
reconfigured at runtime based on the actual pool us- 
25 age. 



=> Thread-pool optimization timer: Upon expiration of 
such timer, the optimization process should be ap- 
plied (i.e. unused threads released) . 

30 

♦ Timers (cf . Tab. 19) . 



Mutex : 
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* Timer for detecting potential indefinite lock of the 
mutex, eventually with the aid of a low-priority in- 
stance of the FSM 106 (cf . TM in Tab. 19) . 

* The number of attempts to get said mutex is limited by a 
maximum number (Max-Attempts) . 

The SIP UA implementation 110 shall allow configuring at 
least the following parameters: 

♦ Underlying Session Protocol: This is the protocol used by 
E2ENP for carrying its meta-messages (SIP, RMI, socket) . 
In future specifications of E2ENP, other session-layer 
protocols could be used (e.g. H323) . 

♦ Underlying Transport Protocol: The type of transport pro- 
tocol to be used by SIP. In future specifications, this 
parameter might become a configuration parameter of the 
SIP UA 110 itself. 

The following subsection provides information about the deci- 
sion to make communication between the E2ENP UA 128 and the 
Parser 112 respectively the Factory 114 synchronous. In this 
connection, the E2ENP UA 128 shall support multiple concur- 
rent instances of the E2ENP UA FSM 10 6. In order to avoid an 
unbounded usage of OS resources, the E2ENP UA 128 shall en- 
force a thread pool. 

Communication between the E2ENP UA 12 8 and the Parser 112 re- 
spectively Factory 114 could also be asynchronous, e.g. im- 
plemented by an active request interface and a passive con- 
firmation interface. This option is not used within the scope 
of the underlying invention because some gain in performance 
and flexibility is opposed by much more complicated state 
models for the FSMs 106 of the E2ENP UA 128. 
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One consequence of this decision is that the E2ENP UA 128 
and the Parser 112 (also the Factory 114) communicate syn- 
chronously, thus having to share a common address space, 
which in most circumstances is a reasonable assumption. An- 
other consequence of this decision is that both the Parser- 
Factory and the FactoryFactory have to be designed as thread- 
safe, re-entrant libraries. 

Due to the discussion above, it is decided that communication 
between the E2ENP UA 128 and the Parser 112 as well as the 
Factory 114 is synchronous. 

In conclusion, the main advantageous differences between the 
underlying invention and the state of the art shall be empha- 
sized. Briefly summarized, the main benefits of the proposed 
approach consists in 

- a QoS pre-negotiation with a lease-based management of pre- 
negotiated information, QoS negotiation, and QoS re-nego- 
tiation, and 

- a resource reservation and/or release coordination offered 
by the E2ENP UA 128. 

Moreover, the information to be negotiated (capabilities, ap- 
plication-level QoS Contracts, network-level QoS Contracts, 
stream-level adaptation paths, and stream-group-level adapta- 
tion paths) can be expressed in an interchangeable format in 
such a way that heterogeneous applications 130 and/or middle- 
ware 130 can easily agree on a reference model, which said 
applications 130 and/or said middleware 130 can then use for 
dynamically configuring Finite State Machines 106 (FSMs) in 
order to orchestrate local, peer, and network resources ac- 
cording to the preferences and profiles of the respective 
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user, policies of the respective systems and network provid- 
ers in a coordinated manner among a plurality of heterogene- 
ous applications 130 and middleware 130 used by various 
peers - 

Finally, said E2ENP UA 128 can be used for any session-layer 
protocol and session description language, a plurality of ap- 
plications 130 and different types of middleware 130. 
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Table A: Used Abbreviations 09. DeZ. 2002 



Abbr. 


Brief Explanation 


ABNF 


Augmented Backus -Naur Form 


API 


Application Programming Interface 


ASCII 


American Standard Code for Information Interrhanno 


E2ENP 


End-to-End Negotiation Protocol 


FSM 


Finite State Machine " " ~~ 


IF<X> 


Interface <X> " " : ; 


IP 


Internet Protocol 


IPv6 


IP version 6 


LAN 


Local Area Network 


MIME 


Multi-Purpose Internet Mail Rxi-pn^i n n<? 


MSC 


Message Secruence chart TnMTTl ' 


OS I 


Open Systems Interconnection 


QoS 


Quality of Service 


RMI 


Remote Method Invocation 


RPC 


Remote Procedure Call " 


SAP 


Service Access Point ~~ " ' — 


SDP 


Session Description Protocol 


SDPng 


Session Description Protocol (next generation) 


SIP 


Session Initiation Protocol 


UML 


Unified Modeling Language 


XML 


Extensible Markup Language 
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Table B: Depicted Features and their Corresponding 
Reference Signs 



No. 


Technical Feature 


100 


block diagram showing the applied architecture for the 
User Agent (UA) of the End-to-End Negotiation Protocol 
(E2ENP) according to the underlying invention 


101a 


E2ENP Management API (= interface IF1) between the E2ENP 
UA Factory 108 and the Management Entities 102 


101b 


E2ENP UA API (= interface IF2) between the E2ENP UA 128 
and any application 130 or middleware 130 using the 
services offered by said E2ENP UA 128 


101c 


SIP UA Generic API (= interface IF3) between the E2ENP 
UA FSM 106 and the carrier protocol UA 110 (SIP, RMI, 
etc.) 


lOld 


Parser API (= interface IF4) between the E2ENP UA FSM 
106 and the implemented Parser 112 


lOle 


Factory API (= interface IF5) between the E2ENP UA FSM 
106 and the implemented Factory 114 


102 


E2ENP_ Management Entities of the E2ENP architecture 100 


103 


Cache API between the Cache 104 and the E2ENP UA FSM 10 6 


104 


two-stage Cache of the E2ENP architecture 100, connected 
to the Finite State Machine (FSM) 106 of the E2ENP User 
Agent (UA) 128 


106 


Finite State Machine (FSM) applied to the E2ENP User 
Agent (UA) 128 of the E2ENP architecture 100 


108.. 


E2ENP UA. generation .factory of the .E2ENP architecture 
100 


108a 


SIP-based E2ENP UA generation factory of the E2ENP 
architecture 100 


110 


placeholder for the implementation of the carrier proto- 
col (SIP, RMI, etc-) User Agent (UA) , also referred to 
as Service Provider 


110a 


SIP User Agent (UA) used for the UA implementation 110 
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| Technical Feature 



110b 



110c 



112 



112a 



112b 



114a 



114c 



I of the carrier, protocol within the applied E2ENP 
architecture 100 according to the first implementation 
example 200 

I Java Remote Method Invocation (RMI ) -based User Agent 

(UA) used for the UA implementation 110 of the carrier 
Iprotocol within the applied E2ENP architecture 100 
according to the second im plementation example 300 
socket-based User Agent (UA) used for the UA 
I implementation 110 of the carrier protocol within the 
| applied E2ENP architecture 100 according to the third 
implementation example 400 
| Placeholder tor the implementati on of the applied Parser 

farser used for the Parser implementation 112 of 
[the applied E2ENP architecture 100 according to the 
first implementation example 200 



Dummy Parser used for the Parser i mplementation 112 of 
the applied E2ENP architecture 100 according to the \ 
(second implementation example 300. The Dummy Parser is 
[used together with the Java RMI based UA 110b. 



I Dummy Parser used for the Parser i mplementation 112 of 
the applied E2ENP architecture 100 according to the 
third implementation example 400. The Dummy Parser, is 

[used together wi th the socket based UA 110c. 

placeholder for the implementat ion of the applied 
Factory 



|SDPng Factory used for the Factory implementation 114 of 
the applied E2ENP architecture 100 according to the 

(first implementation example 200 

mummy Factory used for t he Factory implementation 114 of 
the applied E2ENP architecture 100 according to the 
second implementation example 300. The Dummy Factory is 

[used together with the Java RMI based UA 110b. 



|uummy Factory used for t he Factory implementation 114 oT 
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Technical Feature 




the aoolied E2ENP architecture 100 according to the 
third implementation example 400. The Dummy Factory is 
used together with the socket based UA 110c. 


1 1 fx 
X JL \J 


r^on t* i nn far1"nrv nf the carrier protocol User Aoent 
(UA) implementation 


116a 


JSIP agent 110a generation factory for the carrier 
implementation example 200 


116b 


RMI agent 110b generation factory for the carrier 
protocol User Agent 110 for Java RMI according to the j 
second lnipieiucnuaLion exampxe ouu 


116c 


Socket-based agent 110c generation factory for the 
carrxer prouocoi user Agent, iiu ior socjvcl jjcidcu. 
connections according to the third implementation 
example 400 


I 1 Q 

II O 


bensrauion zacnory or une appiiea. rarscr lnipxciuenLaLion 
112 


118a 


SDPng Parser 112a generation factory (ParserFaetory) of 
tne appneu JraxTser ±±^ accoraing to uxie iiro t 
implementation example 200 


118b 


Dummy Parser 112b generation factory (ParserFaetory) of 
implementation example 300 


HOC 


Hi iTTnn\r Parcor T 1 O o rronorat'l on "F^ot" o>~\jr /PflrQorVflr+'rtrw^ o*F 
u LilLLiliy roi oci 1 ytnitrx ct i — luii l au luj, y \rai ocirauuuiy / j_ 

the applied Parser 112 according to the third 
implementation example 400 


X £. \J 


f2on pra 4~ "i on • f apf orv- o "F +■ p»- annl *i pr] T^a rt"nrv iTnT>l ^Tn^n+*^1""i on 

114 


120a 


SDPng Factory 114a generation factory (FactoryFactory) 
of the applied Factory 114 according to the first 
implementation example 2 00 


120b 


Dummy Factory 114b generation factory (FactoryFactory) 
of the applied Factory 114 according to the second 
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implementation example 300 


120c 


Dummy Factory 114c generation factory (FactoryFactory) 
of the applied Factory 114 according to the. third 
implementation example 400 


122 


Java based SIP stack (JSIP) applied as a component of 
the said SIP User Agent (UA) 110a 


124a 


Remote Method Invocation (RMI) skeleton of the Java RMI- 
based User Agent (UA) 110b according to the second 
implementation example 300 


124b 


Remote Method Invocation (RMI) stub of the Java RMI- 
based User Agent (UA) 110b according to the second 
implementation example 300 


126a 


TX socket of the socket-based User Agent (UA) 110c 
according to the third implementation example 400 used; 
for transmitting strings or objects 


126b 


RX socket of the socket-based User Agent (UA) 110c 
according to the third implementation example 400 used . 
for receiving strings or objects j 


126c 


Adapter of the socket-based User Agent (UA) 110c 
according to the third implementation example 400 used 
for receiving and/or transmitting strings or objects 
using the said sockets 12 6a+b 


128 


combined unit comprising said Cache 104, said E2ENP UA 
FSM 106, and said E2ENP UA Factory 108, in the following 
referred to as E2ENP-based User Agent (E2ENP UA) 


130 


multi-session multimedia application or QoS Broker 
(middleware) using the E2ENP UA API 101b to connect with 
the E2ENP UA 128 


200 


first implementation example of the applied architecture 
for the User Agent (UA) of the End-to-End Negotiation 
Protocol (E2ENP) according to one embodiment of the 
underlying invention using a Java based SIP Stack (JSIP) 
and SDPng Parser and Factory 
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|No. 
■ 300 


| Technical Feature " r 


i ^v^a*^ xm^-Ltiiuentaxiion example of the applied 
architecture for the User Agent (UA) of the End-to-End 
Negotiation Protocol (E2ENP) according to one embodiment 
of the underlying invention using Sun's Java Remote 
Method Invocation (RMI) 


400 


third implementation example of the applied architecture 
xor cne user Agent (UA) of the End-to-End Negotiation 

1 Protocol firoi?'M"D\ 9n^«.^4 «~^. j_ 

OCOCOi IJWBNPj according to one embodiment of the 

underlying invention using the socked-based User 

9ram protocol (UDP) or Transmission Control Protocol 
(TCP) 


500 


UML class diagram showing the org: : mind: : e2enp packaae 


502 


j^ciNiru^erAgentJjistener interface within the 
org: :mind: :e2enp package 


504 


Provider interface within the org :: mind: : e2enp package 


506 . 


^n„mum lULexidce, generalized to said interface 
SLener ou ^ Wlthln the org: : mind: :e2enp package 


508 

1 .*"■*« * I 


imuwuieii4ibL«iiex interlace, generalized to said 

interface Li Rt"pnpr ^ no t r -i -t-^-s 4-1 

c -uj-sxener 3U2 within the org: : mind: : e2enp 

package • • . , ... ^ 


\510 [ 


ManagerProvider interface " — ' ; 


512 


ManagerListener i nf^rf ^n/a — ■ 


514 


class ConfigurationRequest — 


516 


class Parser FactoryConf iguration " ■ 


600 


y jjacKua Weiur iorm (abnf) of the E2ENP address 
as a Universal Resource Identifier (URI) 


700- j 


first message sequence chart (MSC) showing the pre-nego- 

ptoceaure enabled by the User Agent (UA) 128 of 
the End-to-End Negotiation Protocol (E2ENP) 


702 j 

] 


ciass urrererServiceUser, derived from the class " 

E2ENPUserAgentListener, implementing the Listener 
interface 502 


704 < 


:lass OffererServiceProvider, derived from the class 
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Technical Feature 



Provider, which implements the Provider interface 504 



class AnswererServiceProvider, derived from the class 
Provider, which implements the Provider interface 504 



class AnswererServiceUser, derived from the class 
E2ENPUserAgentListener, implementing the Listener 
interface 502 



second message sequence chart (MSC) showing the session 
establishment with a QoS negotiation and resource 
reservation coordination enabled by the User Agent (UA) 
of the End-to-End Negotiation Protocol (E2ENP) 



UML class diagram showing the org: : mind: : e2enp: : Cache 
sub-package 



class LevelOneCache representing the f irst level (LI) of 
the two-stage Cache 104 . . 



class LevelTwoCache representing the second level (L2) 
of the two-stage Cache 104 



class LevelOneEntry encompassing metho ds for storing and 
loading information to/from the first level (LI) of. said 
two-stage Cache 104 

class LevelTwoEntry encompassing methods tor storing and 
loading information to/from the second level (L2) of 
said two-stage Cache 104 , 



1000 



1001 



1002 



1003 



1004 



1005 
1006 



diagram showing the top-level view of an Extensible — ~ 
Markup Language (XML) description used for the End-to- 
End Negotiation Protocol (E2ENP) 



Complex Type definition descType of the SDPng desc 

element. The illustration also incorporates the E2ENP 
specific changes made by the redefine mechanism. 



.e2enp: purpose" child element of the „desc" element" 



sdpng:def" cnild element of the „desc" element. 



sdpngtcfg" child element of the „desc" element. 



sdpng: constraints" child ele ment of the „desc" element, 
sdpng:conr- child element of the „desc" elerniHt" 
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1100 


uxayicuu oiiuwxiiy tne Al w JJ_i oLLUo LILULIOII groups US6Q tor tn© 
End" - to ~Enci Necroti ati on Prnfonnl ( TT Qttmtd \ 


1101 


CohtdIgx TVDfi de f init i nn He* c^Tvrrvo n-F fha Qnpnrr Hqo^ 

e lement . The illustration also l nrnmnrat-oc +-v, Q vottmd 

specific chancres made bv the redefine Tnorh^ni <?m 


1102 


«e2eno rouroose" child ^lpm^nt o*f t-ho Hocn xx Qmon+- 


1103 


„sdpng:def w child element of the „desc" element. 


1104 


„sdpng:cfg M child element of the „desc*> element. 


J. J. V J 


„5apng , constraints cniia element or the „desc element. 


1106 


„sdpng:conf" child element of the „desc" element. 


J. -L U / 


w 5apng;a- element, neaa or tne suJbstitution group which 
defines the valid child elements of the „sdpng:def" 

- SI 4— A /SM ■ 

octLlOn* 


1108 


„audio: codec" element, member of the „sdpng:d" 
bLujotitution group. 


1109 


„e2enp: qosdef " element, member of the „sdpng:d" 
substitution group. 


1110 


,,rrp.pt element, memoer or tne „sdpng:cL" substitution 
group. 


1111 
nil 


rr*- «-F • naasport" element/ memoer o£ tne „sdpng:d NV 

substitution group. This element in turn is head of the 
rt*- ^-h* • txanopui t siiDstitution group . 


1112 


„rtp:udp" element, member of the „rtp : transport" 

substitution rrrnnn 


1113 


„ video : codec" element, member of the „sdpng:d" 
substitution group. 


1200 


uxay±cuu biiowmg tne Ai v ijj purpose element used for the 
End-to-End Negotiation Protocol (E2ENP) 


1201 


^purpose" element. Can be used to convey additional 
information about the description following in the 
protocol data unit (PDU) . 


1202 


„e2enp:use" element. Child of the „purpose" section, can 
be used to indicate referenced sessions. \ 
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1203 


//description^, element . Can be used to inriirafp a 
description PDU. 


1204 


//mediation" element. Can be used to indicate a mediation 
PDU. 


1205 


„e2enp: session" element 


1206 


„expires" element ■ - 


1300 


^ oiiuwxuy uiic ^viii-i 4Ubuei exemenu usgq ror the End - 
to-End Negotiation Protocol (E2ENP) 


1300' 




1301 


//audio : codec" element. Describes an audio capability of 
the svstpm 


1302 


„ video : codec" element. Describes an video capability of 
the svstem 


1303 


„rtp:pt" element. Can be used to specify a desired 
^/aju.wau j-wiuiciu j-uir a given capaox x 1 ty # 


1304 


„e2enp: policy" element* Can be used to specify the 
resource inanarfAinpn+* nni ■? r*\7 +-/->, 

wv -*-*- iuaaay euicii u policy LO eniOrCG • 


1305 


„e2enp: audio" element. Can be used to describe the QoS 
contracts for anH{ n «3 +- ro^mc 


1306 


„e2enp: video" element. Can be used to describe the QoS 
contracts for video sfrp^nc; 


1307 


„e2enp: control" element- Can be used to describe the QoS 
contracts for control streams . 


1308 


ff wfa^,uaua ts-LesiiieiiL. • ^axi xje uscQ to . Describe the QoS 
contracts for data streams 


1309 


„r tp : map" element . Can hp ii<?e*ri Fn h^fTtTZ S rn^^TTTrz ■ — 

between an application level OoS Contract anH » eno «4 f ^ 
RTP payload format. 


1310 


/ ,e2enp: contract" element 


1311 


^predicate" element ~ 


1312 


^criterion" element ~ ■ 


1400' 


XML qoscfg element " ■ 


1400 


diagram showing the XML qoscfg element used for the End-" 
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to-End Necrotiation Protocol (E2ENP) 


1401 


„e2enp : context^ element Can be used to define 
associations between data streams and tbus to exnrpqq 
time synchronization and/or OoS correlation. Brief lv. 
this element defines high level QoS Contracts. 


1402 


„e2enp : adapath" element 


1403 


„default xx element 


1404 


„alt M element 


1405 


„ event x> element 


1406 


„path" element 


1407 


„comp" element 


1408 


constraints" element 




^par e±emenu 


1500 


UML message sequence chart (MSC) showing the interaction 
Detween une rjZJiiJNir user Agent (UA) 12 o accordxng to the 
underlying invention and the applied Parser 112 and 
Cache 104 




urojj ciass diagram snowing tne general structure of a 
Document Object Model (DOM) tree 


1702 


class DocumentTree, which- models the general structure 

oaj - u j-^wi w i nee ana can unereioiG db interpreted as the 
document root element 


1704 


class DocumentNode aggregated to said class DocumentTree 
1702, which in turn aggregates between 0 and n children, 
U1XU.O icuuioxveiy u.t=oCi ijyjLxiy Liiti tree s l. rucrurG 


1800 


UML class diagram showing a structural overview of the i 
Parser iiRDrpitipnt*ai*i nn 11? n^inrr » \ri ci •f-^-r- Hae-i rm 
pattern" for traversing the DOMTree 1804 and generating 
a XMLObject 1802 


1802 


class XML Object used within the Parser implementation 
112 


1804 


class DOMTree, which models the general structure of 
said DOM tree and can therefore be interpreted as the 



F *b!4l8 EP and P 26149 EP 

10. 



Technical Feature 



document root, element 



1806 
1808 



class DOMNode aggregated to said class DOMTree 1804 



generic Parser visitor class pVisitor, which visits 
between 1 and N DOMNodes 

tirst specialized DOMNode of said class DOMNode 1806 



1810n 



N-th specialized DOMNode of said class DOMNode 1806 



first specialized Parser visitor class pVisitor 1, which 
is applied to handle the first derived DOMNode 



1900 



2004 



2006a 



2008a 



2008n 



2100 



2102 



N-th specialized Parser visitor class pVisitor N, which 
is applied to handle the N-th derived DOMNode 



UML message sequence cnart (MSC) showing the interaction 
between the E2ENP User Agent (UA) 128 according to the 
underlying invention and the applied Factory 114 and 
Cache 104 



UML class diagram showing a structural overview of the 
Factory implementation 114 



generic Factory visitor class fVisitor, which visits " 
between 1 and N instances -of ObjectGraphNode classes 



class ObjectGraphNode used within the Factory 
implementation 114 



first specialized Factory visitor class fVisitor 1, 

which is applied to handle the first derived Node 2008a 
of the class ObjectGraphNode 2004 

N-tn specialized Factory visitor class fVisitor N, which 
is applied to handle the N-th derived Node 2008n of the 
class ObjectGraphNode 2004 



first specialized Node (subclass) of the class" 
ObjectGraphNode 2004 



N-th specialized Node (subclass) of the class 
ObjectGraphNode 2004 



UML class diagram showing the org; ; mind: : s ip: ;sipApi ' 
package 



class management of the org: : mind: : sip: : sipApi package" 
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2104 


class userAgent of the org: : mind: : sip: : sipApi. package 


2106 


class registrar of the org: : mind: : sip: : sipApi package 


2107 


class time of the org: : mind: : sip: : sipApi package 


2108 


interface SipListener of the org: : mind: : sip: : sipApi 
package 


2110 


interface SioProvider of the orcr: :mind: :sio: : sidAdi 
package 


2112 


class SioExniresHandlincr of t*h^ orcr' •mind* *sio* • sinAni 
package 


2114 


class SiryEndUs^r' of the* orcr* "mind* •<5ir>* • ^inADT narkaap 


2200 


UML class diagram showing the 

org: :mind: :sip: : sipApi: : userAgent package 




org: :mind: :sip: : sipApi: : userAgent package 


2204 


interface SipUserAgentServerListener of the 

uiy . •iLixxiu. *oxp* • oip^pj. • » uociA^cxit. paCJvaycf aciiveci jLiOiu 
the class SipUserAgentListener 2202 


2206 


org: : mind: : sip: : sipApi :: userAgent package, derived from 


2208 


Class SipConnectionReq of the 

orcr: :mind: :sio: :si"DAr>i: mserAaent rjackacre 


2210 


interface SipUserAgentType of the 

org: :mind: :sip': : sipApi: :userAgent package 


2212 


interface SioUserAaentFactorv of the 
org: :mind: :sip: : sipApi: : userAgent package 


2214 


class SipUserAgent of the 

orcr: :mind: :sio: :sit>Aoi: :userAcrent t>ackacre* derived from 
the class SipUserAgentType 2210 


2214a 


class UAClient of the 

org: : mind: : sip: : sipApi :: userAgent package, derived from 
the class SipUserAgent 2214 


2214b 


class UAServer of the 
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org: rmind: :sip; rsipApi: ruserAgent package, derived f rom. " 
the class SipUserAgent 2214 


2216 


class SipNegotiationModel of the 

org: :mind: :sip: :sipApi: :userAgent package 


2218 


class SipRegistrationReq of the 

org: :mind: :sip: :sipApi: :userAgent packaae 


2220 


class SipRegistrationCfm of the 

org: :mind: :sip: :sipApi: :userAcrent r>arkarr*» 


2300 


UML class diagram showing the ~ : " 

org: :mind: :sip: rsipApi: :recristrar narkanp 


2302 


interface SxpRegistrarListener of the 
org: :mind: :sip: :sipApi: registrar package 


2304 


interface SipRegistrarTvpe of t-h<=> ~~ 

org: : mind: : sip: :sipApi: registrar package 


2306 


class SipRegistrar of the : " ~ 

org: :mind: :sip: :sipApi: registrar package, derived from 
said class Sip- RegistrarTvoe 2304 


2308 


class SipRegistrationlnd of the : : ; — 

org: :mind: : sip :: sipApi :: registrar r>aokarr^ " 


2310 


class SipRegistrationRsp of the ~~ ' 

org: mind: :sip: :sipApi: : registrar packaae ' 


2312 


interface SipRegistrarFactory of the ! ~ 

org: :mind: :sip: :sipApi: : registrar packaae 


2400 


UML class diagram showing the : : - 

org: :mind: :sip: :sipApi: rmanagement nackaae 


2402 


interface SipManagementListener of the : 

org: :mind: :sip: :sipApi: management nackaap 


2404 


interface SipManager of the " 

org: :mind: :sip: :sipApi: management package 


2406 


class SipConfigurationReq of the ' 

org: :mind: :sip: :sipApi : management package 


2500 


UML class diagram showing the " 

org: mind: :sip: : sipApi : : time package 
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2502 


interface SipExpiresType of the 
org: :mind: :sip: : sipApi: :time package 


2504 


class SipParseException of the 

org: :mind: : sip : : sipApi : : time package 


2506 


class SipExpires of the 

org : : mind : : sip : : sipApi : : time package 


2508 


111L.C1 JL a^c u JL^JjA^Xi, Co I; LUi y Ui. L-ilc? 

org: :mind: :sip: : sipApi: :time package 


2600 


UML message sequence chart (MSC) showing the 

Pnnf 1 fTIl V* ^ "i rsn r^"P +"T^ca Qorwi r^a Prrvtri Hor s»T^r^ +*V*^ V*\ -5 t-i rr 
uuui xy ui a uxuxi vj L. Ullc DciVlCc rlU VI KX^z. L. ctllvJL uiie DinCLXilCJ OX 

the Service User with said Service Provider 


2700 


UML message sequence chart (MSC) showing the connection 
uciijjL i siiiiieii c Detween uxie user Agents ox a cusnt and a 
server 


9800 
£* o \J \j 


method used for the End-to-End Negotiation Protocol 
(E2ENP) 


2900 


uii-u iiicooayc oc4uciiuc oiiax l ^i v iov^.j o now j>xiy tne conneccion 
release between the User Agents of a client and a server 


3000 


first state transition diagram. for a nested Finite -State 

- L - lcl ^- L - L J - AJ - C ^on; oiiuwxiiy Liic iliu. Utriv rclaLcU procedures 

executed in the root state 


3100 


second state transition diagram for a nested. Finite 

State Machines (FSM. showincr i~Y\ & Tnnfpv— r^l =» f e^H nrnroHn voc? 

executed in the NegOfferer sub-state 


3200 


third state transition diagram for a nested Finite State 

Machine (FSMV showincr the mnt^x— *re±l at-e*r\' nrnrpdnrpq 
executed in the NegAnswerer sub- state 


3300 


fourth state transition diagram for a nested Finite 
State Machine (FSM) showing the mutex-related procedures 
executed in the ReNegOfferer sub-state 


3400 


fifth state transition diagram for a nested Finite State 
Machine (FSM) showing the mutex-related procedures 
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3500 



3600 



3700 



3702 



3708 



3800 



3900 



[executed in the ReNegAnswerer sub-state 
sixth state transition dxagram f or the _ResvMtx Finite 
State Machine (FSM) for allowing multiple requests to 
seize the mutex in a coordinated manner, based on their 
priority 



seventh state transition diagram tor a nested Finite 

State Machine (FSM) showing the mutex-related procedures 
executed in the WaitF orCoordDone sub-state 
um. message sequence chart (MSC) showing the pre-nego- 
tiation procedure needed for the correlation of the 
Application Programming Interface (API) of the E2ENP 
User Agent (UA) and the generic Application Programming 
Interface (API) of the SIP User Agent (UA) , thereby 
using the above-mentioned Finite State Machine (FSM) of 
the E2ENP User Agent (UA) 



class OfferersiPServiceUser, imple menting the interface 
I SipUserAgentClientListener 2206 



class OffererSlPServicePr ovider, derived from the class 
SipUser Agent 2214 

class AnswerersiPServiceProvider, d erived trom the class" 
SipUserAgent 2214 

class AnswerersiPService user, implementing the interface " 
SipUserAgentServerListener 2204 

uku, message sequence chart (MSC) showing the session 
establishment with the QoS negotiation procedure and the 
resource reservation coordination needed for the 
correlation of the Application Programming Interface 
(API) of the E2ENP User Agent (UA) and the generic 
Application Programming Interface (API) of the SIP User 
Agent (UA) , thereby using the above-mentioned Finite 
State Machine (FSM) of the E2ENP User Agent (UA) 



xaiD. i: table snowing a list of primitives implemented 
| by the service Provider, based on a Java implantation 
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of the Application Programming Interface (API) applied j 
to the User Agent (UA) of the End-to-End Negotiation 
Protocol (E2ENP) 


a non 

ft UUU 


implemented by the Service User, based on a Java 
implementation of the Application Programming Interface 
(API) applied to the User Agent (UA) of the End-to-End 
Negotiation Protocol (E2ENP) 


4100 


Tao . 3 : taoie snowing a 11st or primitives to oe 
implemented by the Service User acting as an Offerer, 
based on a Java implementation of the Application 
Programming . Interface (API) applied to the User Agent 
(UA) of the .End- to-End Negotiation Protocol (E2ENP) : 


4200 


Tab. 4: table showing a list of primitives to be 
implemented by. the Service User acting as an Answerer, 
based on a Java implementation of the Application 
Programming mtertace (Airi) applied to trie user Agent: 
(UA) of the End-to-End Negotiation Protocol (E2ENP) 


4300 


Tab.. 5: table showing the methods provided by the 
Application xrjroy iraiuming interlace \j\ita.) oi txxe nrst 
Cache level 


4400 


Tab. 6: table showing the methods provided by the 

iipp llCatlUIl riUy I cUUIUXIiy Ifltcilatc J. / tJJ- tile o ci tvJIltL 

Cache level . 


a c^on 
ft 5UU 


i aD • . / • Louie snowing a. xibL' t>±. px.iiaiti.vei5 wiij.cxi uave to 
be implemented by the Application Programming Interface 
(API) .of- the Parser 


flOUU 


± cllj . o . Louie oixLJ wniy d xio l> \J j- pi iilii ui vco wuiV/H nave l-vj 

be implemented for generating a specific parser instance 


4700 


Tab. 9: table showing a list of primitives which have to 
be implemented by the Application Programming Interface 
(API) of the Factory 


4800 


Tab. 10: table showing a list of primitives which have 
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to be implemented for generating a specific factory 
instance 


4900 


Tab. 11: table showing the methods provided by the well- 
known factory-factory class E2ENPContentHandlerFactory 


5000 


Tab. 12: table showing a list of primitives implemented 
by the Service Provider, based on a Java implementation 
of the generic Application Programming Interface (API) 
applied to the User Agent (UA) of the End-to-End 
Negotiation Protocol (E2ENP) 


5100 


Tab. 13: table showing a list of client-side-specific 
primitives implemented by the Service User, based on a 
Java implementation of the generic Application 
Programming Interface (API) applied to the User Agent 
(UA) of the End-to-End Negotiation Protocol (E2ENP) 


5200 


Tab. 14: table showing a list of server-side-specific 
primitives implemented by the Service User, based on a 
Java implementation of the generic Application 
Programming Interface (API) applied to the User Agent ..' 
(UA) of the End-to-End Negotiation Protocol (E2ENP) 


5300 


Tab. 15: table showing a list of both client-side- and 
server-side-specific primitives implemented by the 
Service User, based on a Java implementation of the 
generic Application Programming Interface (API) applied 
to the User Agent (UA) of the End-to-End Negotiation 
Protocol (E2ENP) 


5400 


Tab. 16: table showing a list of primitives implemented 
by the Service Provider, based on a Java implementation 
of the generic Application Programming Interface (API) 
cx r f t j l-^j Liit; ubcx Hyeut \ u/\ ) oi une iLno— no— cjnd 
Negotiation Protocol (E2ENP) 


5500 


Tab. 17: table showing a list of primitives implemented 
by the Service User, based on a Java implementation of 
the generic Application Programming Interface (API) 
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applied to the User Agent (UA) of the End-to-End 
Negotiation Protocol (E2ENP) 


5600 


Tab* 18: state transition table showina a survev of -hb^ 
applied exception events 


5700 


Tab. 19: table showing the applied timers applied to the 
End-to-End Negotiation Protocol (E2ENP) according to the 
underlying invention 



P 26921 EP and P 26922 EP 

94 



EPO- Munich 
46 

Claims Oa Dez. 2002 



1. A system offering an Application Programming Interface 
(101b) for multi-stream multimedia applications (130) running 
on at least two registered end peers participating in a mo- 
bile telecommunication session and/or middleware (130) being 
connected to a mobile network, said system (128) providing 
guaranteed end-to-end quality and resource capabilities using 
the concept of concatenated E2ENP phases and being adapted to 
provide 

- a pre-negotiation of a multiplicity of alternative capa- 
bilities and QoS Contracts, 

- management of leased pre-negotiated information, 

- session establishment between said end peers with negotia- 
tion of a multiplicity of alternative capabilities and/or 
QoS Contracts, and 

- a dynamic re-negotiation of the end-to-end quality and ca- 
pabilities, 

wherein the information to be negotiated is expressed in an 
interchangeable format so as to allow said multi-stream mul- 
timedia applications (130) to agree on a specific reference 
model of the negotiated information, which can then be used 
for dynamically configuring Finite State Machines (106) to 
orchestrate local, peer, and network resources according to 
the preferences and profiles of the respective user. 

2. A system according to claim 1, 
characterized in that 

said system (128) is internally decomposed into a set of Fi- 
nite State Machines (106) coordinating the internal processes 
and Application Programming Interfaces (lOla-e) . 
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3. A system according to claim. 2, 
characterized in that 

said multi-stream multimedia applications (130) and/or said 
5 middleware (130) use said Finite State Machines (106) for a 
dynamic configuration. 

4. A system according to anyone of the preceding claims, 
characterized in that 

10. it is designed to support multiple concurrent users. 

5. A system for establishing a session between two entities 
in a telecommunications network, said unit (128) comprising 
the -following Application Programming Interfaces (APIs): 

15- - a Management API (101a) representing an interface (IF1) be- 
tween the unit (128) and an entity (102) managing it, 

- an API (101b) representing an interface (IF2) between the 
unit (128), middleware (130) and/or an application (130) 
using services offered by the unit (128), 

20, - a generic session-layer protocol API (101c) representing an 
-... interface (IF3) between, the unit (128). .and a User. Agent . . ■ - 
, (110) of a session-layer protocol. 

6. A system according to anyone of the preceding claims, 
25 characterized by 

• a two- stage E2ENP Cache (104) for managing negotiation object 
identifiers in order to decouple the identification scheme of 
a specific application (130). . and/or middleware - (130) from the 
one specified for the E2ENP by non-persistently storing and 
30 retrieving 

- E2ENP session identifiers referring to the respective mo- 
bile telecommunication session, 

- the E2ENP session identifiers referring to the respective 
Service Provider (110) handled by the Finite State Machine 

35 (106) of the unit (128), and 
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- the E2ENP session identifiers referring to the respective 
Service User (130) handled by any application (1.30) and/or 
middleware (130) using the services offered by said unit 
(128). 

7. A system according to anyone of the preceding claims, 
characterized in that 

the unit (128) is adapted to 

- pre-cache information during the execution of a given E2ENP 
pre-negotiation or negotiation procedure, wherein the pre- 
cached data remains cached for future reference during a 
later E2ENP session once the given procedure has been suc- 
cessfully completed, and 

- to cache information which can be applied as a reference to 
data, which has already been (pre-) negotiated among the end 
peers, during a new E2ENP pre-negotiation or negotiation 
procedure . 

8. A system according to anyone of the preceding claims, 
characterized by 

E2ENP session-layer protocol APIs (lOla-e) being independent 
of the actually used session-layer protocol and the session 
description protocol implementations. 

9. A system according to anyone of the preceding claims, 
characterized by 

a Factory API (lOle) representing an interface (IF5) between 
the unit (128) and a Factory instance (114) used for encoding 
an E2ENP session description. 

10. A system according to anyone of the preceding claims, 
characterized by 

a Parser API (lOld) representing an interface (IF4) between 
the unit (128) and a Parser instance (112) needed for decod- 
ing an E2ENP session description. 
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11. A system according to anyone of the claims 9 and 10, 
characterized in that 

the, Parser instance (112) and the Factory instance (114) can 
5 be configured independently by using the same protocol. 

12. A system according, to anyone of the preceding claims, 
based on a novel usage of the Session Initiation Protocol 
(SIP) in conjunction with extensions of the Session Descrip- 

10 tion Protocol (SDP) or Session Description Protocol - Next 
Generation (SDPng), respectively. 

13. A system according to claim 12, 
. characterized in that 

15 the , session-layer protocol, and the Session Description Proto- 
col. (SDP) or Session Description Protocol - Next Generation 
(SDPng), respectively, are independently configurable. 

14. A negotiation method providing guaranteed end-to-end 

20 quality and resource capabilities for multi-stream multimedia 
applications (130) running on at least two registered end 
peers participating in. a mobile telecommunication session 
and/or middleware. (130) being connected to a mobile network 
1 to dynamically adapt to changes in transmission quality, 
25 which is based on extensions of the End-to-End Negotiation 
Protocol (E2ENP) , said method providing 

- a pre-negotiation of a multiplicity of alternative capa- 
bilities and QoS Contracts* 

- management of leased pre-negotiated information, 

30 - session establishment between said end peers with negotia- 
tion of a multiplicity of alternative capabilities and/or 
QoS Contracts and coordination of terminal and network re- 
source reservations, and 

- a dynamic re-negotiation of the end-to-end quality and ca- 
35 pabilities 
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using the concept of concatenated E2ENP phases, 
characterized by the step of 

expressing the information to be negotiated in an inter- 
changeable format so as to allow said multi-stream multimedia 
applxcations (130) to agree on a specific reference model of 
the negotiated information, which can then be used for dy- . 
namically configuring Finite State Machines (106) to orches- 
trate local, peer, and network resources according to the 
preferences and profiles of the respective user. 

15. A negotiation method according to claim 14, 
characterized in that 

the resource reservation coordination process is based on a 
multi-phase call-setup mechanism that makes network QoS and 
security establishment a precondition to sessions initiated 
by the session-layer protocol and described by a session de- 
scription protocol implementation, wherein network resource 
reservation mechanisms are deployed before the session is 
started, 

wherein the E2ENP enforces peers to always exchange messages 
for confirming the completed resource reservation process; 
and wherein said preconditions are mapped to a E2ENP „qosdef« 
section (1300), which either specifies capabilities of a peer 
or defines validated QoS contracts that have been validated 
by entities using the unit (128), and its corresponding nego- 
tiation process. 

16. A negotiation method according to anyone of the claims 14 
and 15, 

characterized by 

a mandatory synchronization of the reservation processes be- 
tween different peers according to an „Economy Principle". 

17. A negotiation method according to anyone of the claims 14 
to 16, 
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characterized in that 

in case no network resource reservation is conducted by the 
end peer at the Offerer side, the unit (128) of another end 
peer acting as an Answerer determines this case by examining 
the preconditions made by the Offerer and correspondingly en- 
ables the Answerer to transparently deal with resource reser- 
vation coordination. 

18. A negotiation method according to anyone of the claims 14 
to 17, 

characterized by the step of 

allowing both end-to-end and segmented reservations, wherein 
network resource reservation is done locally on beforehand 
with no cost and/or major impact on session establishment. 

19. A negotiation method according to anyone of the claims 14 
to 18, 

characterized in that 

in case a multi-stream multimedia application (130) or mid- 
dleware (130) wishes to execute a „pre-reservation" of net- 
work resources, the E2ENP signaling gives the right timing to 
said application (130) or middleware (130), respectively, 
thereby informing it when the resource reservations at all 
sides have been accomplished. 

20. A negotiation method according to anyone of the claims 14 
to 19, 

characterized by 

a new E2ENP syntax which allows that E2ENP addresses (600) 
identifying different E2ENP users, which are passed on by the 
applied pre-negotiation and negotiation primitives and mapped 
to the specific syntax used by the underlying session-layer 
protocol that is used for piggybacking E2ENP information, are 
independent of said session-layer protocol and/or the respec- 
tive transport protocol used underneath by the unit (128) . 



e zx>vzi ep and P 26922 EP 

100 



21. A contention resolution method used for a negotiation 
method according to anyone of the claims 14 to 20, which is 
applied in case of two peers initiating E2ENP phases at the 
same time, 

wherein the E2ENP UA (128) not only include the session 
identifier sent by an Offerer but also a hash thereof as a 
substitute for said session identifier in any subsequent ses- 
sion-layer protocol message which takes the IP address of the 
computing unit where the E2ENP UA (128) is active into ac- 
count and a time stamp, which is applied whenever a negotia- 
tion or pre-negotiation phase is initiated. 

22. A contention resolution method according to claim 21, 
characterized in that 

in case two peers are not already involved. in multimedia ses- 
sions, each peer compares the hash it has generated with the 
one received from the peer, and the peer with the biggest 
value is automatically chosen as Offerer and thus proceeds 
with the pre-negotiation or negotiation phase as such, 
whereas the other peer automatically moves to the Answerer 
mode. 

23. A contention resolution method according to claim 21, 
characterized in that 

in case two peers are already involved in multimedia ses- 
sions, the peer whose request has been rejected applies an 
unplanned re-negotiation, procedure after the peer whose re- 
quest has been accepted has completed its negotiation proce- 
dure. 



24. A telecommunications network, 
characterized in that 

said telecommunications network comprises an system (128) 
cording to anyone of claims 1 to 13. 
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25. A computer software program product , 
characterized in that* 

said computer software program product implements a system 
(128) according to anyone of claims 1 to 13 when running on 
mobile terminal in a wireless network environment. 
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EPO- Munich 
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The underlying invention generally relates to the field of 
mobile computing in a wireless mobile networking environment 
with distributed multimedia applications (130) . More specifi- 
cally, it is directed to the field of Quality-of-Service 
(QoS) management for adaptive real-time services running on 
mobile devices and an End-to-End Negotiation Protocol (E2ENP) 
based on a novel usage of a session-layer protocol (SIP) in 
conjunction with extensions of a session description protocol 
implementation (SDP, SDPng) and the Extensible Markup Lan- 
guage (XML) for defining user profile and terminal capability 
information which allow to enforce and use hierarchical QoS 
Contract specifications. 



Thereby, said End-to-End Negotiation Protocol (E2ENP) is ap- 
plied to derive negotiable information, which enables a pre- 
negotiation, fast negotiation and a fast, dynamic re-negotia- 
tion of the end-to-end quality and capabilities for a tele- 
communication session, for multiple configurations of two or 
a multiplicity of end peers and/or middleware in a consis- 
tent, reliable, and incremental way by enabling the mobile 
applications to efficiently and timely react to QoS viola- 
tions. Furthermore, the invention pertains to the concept and 
realization of a novel E2ENP User Agent (128) which encapsu- 
lates the signaling part of E2ENP and expresses the informa- 
tion to be negotiated in an interchangeable format in such a 
way that heterogeneous applications (130) can easily agree on 
a reference model applied to orchestrate local, peer, and 
network resources according to the preferences and profiles 
of the respective user in a coordinated manner. According to 
one embodiment of the invention, the employed E2ENP session- 
layer protocol Application Programming Interfaces (lOla-e) 
are independent of the actually used session-layer protocol 
35 and session description protocol implementations. (FIG. 1) 
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public void MndReq(OffererServiceUser oSu, AnswererServiceUser aSu, int sptd) " 

Binds the given Service User's event listeners to the given E2ENP UA. 
public void registrationReq(int spld, int serviceUserld, java.lang. String user, 

java.lang. Object info) 

Registers a user with the UA and optionally with a remote registrar, 
public void preNegotiationReq(java.lang. String from, java.lang.String to, int serviceUserld, 

java.lang. Object offer) 

Initiates a pre-negotiation phase, 
public void preNegotiationRspf int serviceProviderld, java.lang.Object answer) 

Answers to an incoming request from the peer for pre-negotiation. 
public void renewLeaseReq(java.lang. String user, int serviceUserld, java.lang.Object offer) 

Initiates a pre-negotiation information lease refresh, 
public void renewLeaseRsp(int serviceProviderld, java.lang.Object answer) 

Answers to an incoming request from the peer for pre-negotiation information lease refresh, 
public void bookNegotiationReq(java.lang. String user, int serviceUserld, int priority) 

Before initiating the negotiation phase, this primitive allows the Service User to book the 

mutually exclusive use of the resource reservation process, with respect to concurrent 

instances of Service Users, 
public void negotiationReq(java Jang. String from, java.lang.String to, int serviceUserld, 

int serviceProviderld, java.lang.Object offer) 

Initiates a negotiation phase, 
public void negotiationStatusRsp(int serviceProviderld, java.lang.Object message) 

Generates an intermediate signaling during negotiation in response to a peer's signaling 
public void bookReNegotiationReq(int serviceUserld, int priority) 

Before initiating the re-negotiation phase, this primitive allows the Service User to book the 
. mutually exclusive use of the resource reservation process, with respect to concurrent 

instances of Service Users. In this case, the serviceProviderld must be specified, 
public void reNegotiationReq( int serviceProviderld, boolean isPlanned, 

java.lang.Object offer) 

Initiates a re-negotiation phase, 
public void reNegotiationRspfint serviceProviderld, java.lang.Object answer) 

Answers to an incoming request from the peer for re-negotiation, 
public void reNegotiationStatusRsp(int serviceProviderld, java.lang.Object message) 

Generates an intermediate signaling during re-negotiation in response to a peer's signaling 
public void startReservationRsp(int serviceProviderld, java.lang.Object result) 

Notifies that the Service User has completed both local and network resource reservation, 
public void releaseRcqfint serviceProviderld, java.lang.Object message) 

Release the given phase (during pre-negotiation and lease renewal) or the overall session, 
public void releaseRsp(int serviceProviderld, java.lang.Object message) 

Replies to a request from the peer to release the given phase (during pre-negotiation and lease 

renewal) or the overall session, 
public void resetReqfmt serviceUserld, int serviceProviderld) 

Resets the given session as an emergency procedure, 
public void resetRsp(int serviceUserld, int serviceProviderld) 

^^^M^^^^^^^^JSc^^^^^^^M^^S^^^^^!^ 
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public void bindCfm (Boolean result) ' : ' **** ~ * 

Returns the result of the bindReq primitive., 
public void registrationCfin(int serviceUserld, java.lang.String user, java.lang. Object info) 

Confirms the registration of the given user with the UA and optionally with an external registry 
public void preNegotiationInd(java.lang.String from, java.lang.String to, int serviceProviderld, 
java.lang.Object offer) 

Notifies the Service User of a request from the peer to initiate a pre-negotiation phase, 
public void preNegotiationCfin(int servicellserld, int serviceProviderld, java.lang.Object answer) 

Notifies the Service User of a reply from the peer concerning the given pre-negotiation 

phase. 

public void renewLeastfhdtint servicellserld, int serviceProviderld, java.lang.Object offer) 

Notifies the Service User of a request from the peer to initiate a pre-negotiation information 
lease refresh. 

public void renewLeaseCfmdnt servicellserld, int serviceProviderld, java.lang.Object answer) 
Notifies the Service User of a reply from the peer concerning the given pre-negotiation 
information lease refresh. 

public void negotiationStatusInd<int servicellserld, int serviceProviderld, java.lang.Object message) 
Notifies the Service User of an intermediate signaling during negotiation, in correspondence 
to a peer's signaling. 

public void bookReNegotiationCfm(int serviceUserld, int servicellserld, boolean IsSuccessful) 

Before initiating the re-negotiation phase, this primitive notifies the Service User that the 

E2ENP UA has successfully booked the mutually exclusive use of the resource reservation 

process, with respect to concurrent instances of Service Users, 
public void reNegotiationIhd{int serviceUserld, int serviceProviderld, boolean IsPlanned, 

java.lang.Object offer) 

Notifies the Service User of a request from the peer to initiate a re-negotiation phase 
public void reNegotiationCfmlint serviceUserld, int serviceProviderld, java.lang.Object answer) 

Notifies the Service User of a reply from the peer concerning the given re-negotiation, 
public void reNegotiationStatuslhdtint serviceUserld, int serviceProviderld, java.lang.Object message) 

Notifies the Service User of an intermediate signaling during re-negotiation, in 

correspondence to a peer's signaling, 
public void startReservationInd(int serviceUserld, int serviceProviderld, java.lang. Object result) 

Notifies that the Service User that is time to start reservation of both local and network 

resources. 

public void releaselndtint serviceUserld, int serviceProviderld, java.lang.Object message) 

Notifies the Service User of a request from the peer to release the given phase (during pre- 
negotiation and lease renewal) or the overall session. 

public void releaseCfmOnt serviceUserld, int serviceProviderld, java.lang.Object message) 

Notifies the Service User of a reply from the peer concerning the release of the given phase 
(dining pre-negotiation and lease renewal) or the overall session. 

public void alertlnd{int serviceUserld, int serviceProviderld) 

Notifies the Service User that a remote peer has called in. 
public void ringBackInd(int serviceUserld, int serviceProviderld) 

Notifies the Service User that the remote peer has been alerted, 
public void congestionlndd'nt serviceUserld, int serviceProviderld) 

Notifies the given Service User instance that other higher priority instances are waiting for 

the mutex to be released. The Service User shall pre-empt by rolling -back to the state before 

the negotiation/re-negotiation started, and invoke the release primitive, 
public void failurelndOnt serviceUserld, int serviceProviderld) 

Notifies the Service User that an E2ENP UA internal error occurred, and that the Service 

User shall invoke the release primitive, 
public void abortInd(int serviceUserld, int serviceProviderld, int reason) 

Notifies the Service User that a SIP error occurred, and that the Service User shall simply 

consider the current operation as aborted. A reason is passed as well, indicating one of the 

possible sources of error 

0 - redirection, 

1 - client error. 



2 - server error, ~™ ^ 

3 -network failure. 

public void resetlnddnt serviceUserld, int service Pro viderld) 

... . . . Notifies the Service User of a request from the peer to concerning the reset of the session 

public void resetCfin(int serviceUserld. int serviceProviderld) 

Notifies t he Service User o f a reply from the peer conceimng|helreset of the session. 
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public void bookNegotiationCfm(int serviceUserld, int servicellserld, boolean isSuccessful) 

Before initiating the negotiation phase, this primitive notifies the Service User that the 
E2ENP UA has successfully booked the mutually exclusive use of the resource reservation 
process, with respect to concurrent instances of Service Users. This primitive is specific of 
the offerer side, whereas the homonymous bookReNegotiationCf m may be invoked 
either at the offerer or at the answerer side. 

public void negotiationCfm(int serviceUserld, int serviceProviderld, java.lang, Object Answer) 
Notifies i^eSgvigiJlJser of a j^lyfrom tt^g^conyraing Ae gyen negotiation. 
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public void nego^ih^dfjavaJang.String from. javaJang:s^g~to. ^^^^T"™— 

int serviceProviderld, java.iang. Object offer) 

nuhllr voirt ™ ^ ^ G Sendce User ofa ^vest fiom the peer to initiate a negotiation phase 
publ.c vo,d complet,onlhd(nt serviceUserld. int serviceProviderld, Object mefsageT 
^ Notifies qgSg^ce, User ti hat the negotiation/set^ phase has been completed successfully 
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public 
LevelOneEntry J 


LevelOneCachccreateEntry (CoreSession session, int serviceProviderld) 
Creates a level 1 entry 


vi..~i«~ .~ ;i 

Dublic i 
LevelOneEntry .1 


LevelOneCachcgetEntry (int serviceProviderld) 

Gets a level 1 entry by using the service provieder ID as primary key 1 


LevelOneEntry J 


T^vplOneCaphe findEntrv ^int serviceUserldl * 
Gets a level 1 entry using the service user ID as secondary key [ 


public 
LevelOneEntry f 


LevelOneCache-fhidEntry (java.lang. String from, java.lang.String to) j 
Gets a level 1 entry using the (From, To) SIP address couple as secondary key I 


public 
java.util.Vector \ 


LevelOneCachcfindEntryByExtSessionldQava.lang. String sessionld) \ 
Gets the level 1 entries by using the E2ENP Session-ID as secondary key \ 


public void 


LevelOneCache.remove£ntry (LevelOneEntry entry) 
Deletes the given entry firorn the cache 


public void | 


I^evelOneCachcclear 0 

Removes all the entries. 


public void 


Level OncEntr>. putS ess ionEDO a va.fang. String sessionld) 

Puts the E2ENP Session-ID in the entry associated with the ghren service 1 
provider ID. 


public j 
java.lang. String ! 


il^velOneEntry.getSessionlD 0 

1 Gets the E2ENP Session-ID associated with the given service provider ID 


— ~ — ~ . - — *x 

public void HLevelOiieEntry.piitServiceUserlD (int serviceUserld) 

1 Puts the service user ID in the entry associated with the given service provider ID. 


public int 


jl^velOneEntry.getServiceUserlD 0 

] Gets a service user ID 


T public int 

1 


|LCTci6neEntry.ge^ei^^ - ...... 

Gets a service provider ID 


1 public void 


]LevelOneEntry.putFromAddress (java.lang.Strlng from) 

1 Puts the SIP From Address associated with the given service provider ID 


} public 

\ java.lang. String 


|LevelOne£ntry.getFromAddres3 0 ~1 
1 Gets the SIP From Addxes s associated with the given service provider ID 


| public void 


| LevelOneEntry.putToAddress Cava. tang. String to) ~\ 
1 Puts the SIP To Address associated with the given service provider ID 

U^.^.............^ — — ♦... 7 A«w»-~.»«»*«..».^^^^ 


1 public 

j java.lang. String 


IlLevelOneEntry.getToAddressO 

| Gets the si P To Addr e s s associated with the given service provider ID 
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public 1 
LevelTwoEntry J 


LevelTwoCachccreateEntry (int serviceProviderld) 
Creates a level 2 entry 


public ~j 
LevelTwoEntry | 


LevelTwoCachcfindEntry Qava.lang. String sessionld) 

Gets all the level 2 entries by using the E2ENP Session-ID as primary key 


public void \ 


LevelTwoCachcremoveEntry (LevelTwoEntry entry) 
Deletes the given entry from the cache 


public void j 


LevelTwoCachccIear 0 ~" 
Removes ail the entries. 


public void 


LevelTwoEntry.putSessionIDOava.lang. String sessionld) 

Puts the E2ENP Session-ID in the entry associated with the given service 
provider ID. 


public | 
java.lang. String j 


LevelTwoEntry.getSessionlD 6 

Gets the E2ENP Session-ID associated with the given service provider ID 


public void 


iivrfT^oEntry.pu^eiriceirserib (int serviceUserld) 

Puts the service user ID in the entry associated with the given service provider ID 


public int 


LevelTwoEntry. getServiceXTserlD 0 
Gets a service user ID 
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java.lang.String 



getType() " 
Returns an identifier to uniquely specffiy the type of this parser. 



boolean 



boolean 



isConf imiExpected ( j ava . io .Serializable Ln) 
Checksall ^media stream definitions for preconditions (PC), and, if at least one such definition 
nasa PC that the offerer is going to carry out reservation, and thus, going to send a 
confirmation to the answerer when done. 



isKeepResultsCached ( java . io- Serializable in) " 

Extracts information about whether the results of a negotiation of re-negotiations should be 
cached or not 



java.lang.Object 



i sRingfiackExpeeted ( j ava . i o . S e ri ali z abl e in ) ~ 

Checks all media stream definitions and returns true, if any of the streams is going to be 
generated bv the answerer. B 



parsePinalResponse ( j ava . io. Serializable in) 
Parses a fin al result message and retains the corresponding status. 



java.lang.Object 



parseLeaseAnswer ( j ava . io . Serializable in) 

Parses a transport representation of a renew lease answer and returns the corresponding obiect- 
representation, k e WJCW 



parseLeaseOffer ( java.io. Serializable in) " " 

^Se^^^° rt repreSentationofa renew lease ofifer ^ retums the corresponding object- 



java.lang.Object 



long 



java.util.Vector 



paxrselieaseTime ( java. io. Serializable in) _ 

Parses a transport representation of a lease answer/offer and returns the corresponding lease 
time as a basic long value. 5 



paxseListOfUsedSessxonlds ( j ava . io . Serializable In) " ~ 

jgjSg^gg"''^ to extract the exfcnttl tepreenMc «, a, „ „, ^ced 




parseNegCOffer ( j ava . io . Serializable in) 

Parses a transport representation of a negotiation counter-offer and returns the corresponding 
object-representation. y e 



java.lang.Object 



parseNegOffer ( j ava . io . Serializable in) " : 

Parses a transport representation of a negotiation offer and returns the corresponding object 
representation. F 5 uujcui 



ava.lang.Object 



Parses a transport representation of a pre-negotiation answer and returns the corresponding 
object-representation. H e 



?arsePreNegOf fer (java . io . Serializable in) 
Parses a transport representation of a pre-negotiation offer and returns the corresponding 
object-representation. & 



ava.lang.Object 



ava.lang.Object 



parseReNegAnswer ( java . io . Serializable in) 
Parses a transport representation of a re-negotiation answer and returns the corresponding 
object-representation. F 5 



ava.lang.Object 



parseReNegCOffer ( java.io . Serializable in) 
Parses a transport representation of a re-negotiation counter-offer and returns the 
corresponding object-representation. 



parseReNegOf f er ( java.io. Serializable in) " " 

Parses a transport representation of a re-negotiation offer and returns the corresponding object- 





Parses a transport representation of a reservation result message and returns the corresnondinsT 
object-representation. wucspunaing 


java.lang.String 


parseSessionId(java.io,Sexiali 2 able in) " ~ 

W^* 6 SiVen jnPUt S6leCtively to extract Vernal representation of the E2ENP session 
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ParserpcreateParserGava.Iang. String protocollD) 
[[Crates a g^er jnstance for the gjy^jTOtoa>l. 



void! registerParserGava Jang .String protocollD, java.lang.String parserClassName) 
j^gistersa parser implementation for the g iven protocol. ...... ^n— 
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java.io.Sertalizab!e 
javaJo.Serialteable 
java.io.Serializable 
java.io.Serializable 

java.io.Serializable 



java.io.Serializable 
java.io.Serializable 
java.io.Serializable 
java.io.Serializable 
java.io.Serializable 
java.io.Serializable 



java.io.Serializable 
java.io.Serializab!e 
long 



javautil. Vector 

java.lang.String 

java.lang.String 
boolean 



______ __ . 49<a> 

createPinalResponse ( j ava . lang. Ob j ect status ) 
Creates the transport repres entation for a final response messa e 

createLeaseAnswer ( j ava . lang . Ob j ect in ) 

Creates the transport rep resentation for a renew lease answer 
createLeaseOf rer (3 ava. lang. Object in) 
Creates the transport re presentation fo r a renew lease offer 
oreateMessage(j ava. lang. object in) 

«=rea-teNeganswer(j ava. lang. Object in) 
Creates the transport represe ntation for a ne gotiation answer 

createNegCOf £er ( j ava . lang . Ob j ect in ) ' 

Creates fee transport representati on for a negotiation counter-offer. 

createNegOf £ er ( j ava . 1 ang . Ob j ect in ) ™~~ 

Creates the transport representation for a neg otiation offi»r 
createPreNegAnswer ( j ava . lang . Ob j ect in ) 
Creates the transport representati on for a pre-ne^ t jation answer 

orearepxeNegOffer(j ava. lang. Object in) 

Creates the transport representation for a ore-neg otiation offer 

createEeNegAnswer ( j a va . lang . Ob j ect in ) ' 

.Creates the transport re presentation for a re-neg otiation answer 

createReNegCOffe*(j ava. lang. Object in) 

Creates the transport representation for a r e -negotiation crmntP r^ 

createlteNegOf £ « ( java . lang . Ob j ect in) 

Creates the transport representation for M ^ -negotiation offer. 

oreateReseirvationltesva t ( j ava . lang . Ob j ect in j" 

Creates the transport r epresentation for a reservation re sult 

getLeasoTiina (java.lang. Object in) " ~ 

^^kase time stored in the internal representation represented by the input 



^!l LiSt ° fUSeClSeSSioaI<is Oava.lang.object in) 
SSt^et^? SeSSi ° n m& St0red in *° mte ^ representation represented by 
getSessionld ( j ava . lang . Ob j ect in ) 

pS^ir ™ m St ° red in int£maI ^ntation represented by the input 
jetType ( ) 

fietorns an identifier to uniquely specifiv the typ e gfthis factor 
IsKeepResuXtsCached ( j ava . lang. Ob j ect in ) 
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1 : 


FactOfYljcreateFaiioryQavaJang.String protocollD) ~"j 
jCreates a factory instance for the given protocol. 


1 . 

i i 


voidljregisterFactoryGava.lang. String protocollD, java.lang. String factoryClassName) 
llRegisters a factory class for the given protocol. 
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abstract Factory 



4300 



abstract Parser 
static 

KENPContentHanrii^rF^^rY 
abstract void 



abstract void 



abstract void 



c^ateFactoa (Java, lang. String protocolID)" 



Creates a fa ctory instance for the g iv en protocol 



createParser (java, j.ang« String protocolID)" 
Creates a p arser instance for th e riwn protocol. 



Provides access to the singleton instance of the 
E2ENPContentHandlerFactory 

^^^g5 ?!^ig^7^ i Pro t ocolI D 7 



j ava • 1 ang .St ring f actoryClassName) 
Registers a factory class for the given p rotocol 
^gxBte^Intpaeri^ntatiot^ii,^ i ^ String ip7 



JS^SKSJS, ^lang. string 

Registers a parser and factory implementation using th e «h™>„ tt> 
rejisterPatsei ( java . -Lang, string protocolID - 
Java. lang. string parserClassName) 
Registers a parser imnlementaHon for the 
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void releaseO 

Shuts down the given SIP U A. 
void bindReq(SipEndUser user, SipUserAgentClientListener ssmlc, 
SipUserAgentServerListener ssmls) 

Binds the given user's event listeners to the given SIP UA. 
void configureReq(SipManagementListener srnl, SipConfigurationReq conf) 

Configures the given SIP UA. 
void connectionReq(SipEndUser user, int connectionld, SipConnectionReq invitation, 
java.io.Serializable message, java.lang .String mimeContentType) 
Allows generating a request to establish a session, 
void connectionRsp(SipEndUser user, int connectionld, int status, 

java.io.Serializable message, java.lang. String mimeContentType) 
Allows replying to a request to establish a session, 
void connectionStatusReq(SipEndUser user, int connectionld, int type, boolean isMiddle, 
java.io.Serializable message, java.lang .String mimeContentType) 
Allows generating provisional responses, 
void connectionStatusRsp(SipEndUser user, int connectidnld, int type, 
java.io.Serializable message, java.lang. String mimeContentType) 
Allows generating explicitly an ACK. 
void disconnectionReq(SipEndUser user, int connectionld, java.io.Serializable message, 
java.lang. String mimeContentType) 
Allows closing a session, 
void disconnectionRsp(SipEndUser user, int connectionld) 

Allows replying to an incoming request to close a session, 
void optionsReq(SipEndUser user, int connectionld, java.lang. String target, 
java.io.Serializable body, java.lang.String mimeContentType) 
Allows sending an OPTIONS, 
void optionsRsp(SipEndUser user, int connectionld, java.io.Serializable body, 
java.lang.String mimeContentType) 

Allows replying to an incoming OPTIONS, 
void messageReq{SipEndUser user, int connectionld, java.lang.String target, 
java.io.Serializable body, java.lang.String mimeContentType) 
Allows sending a MESSAGE, 
void messageRsp{SipEndUser user, int connectionld, java.io.Serializable body, 
java.lang.String mimeContentType) 

Allows replying to an incoming MESSAGE, 
void provisionalAckReq(SipEndUser user, int connectionld, java.io.Serializable message, 
java.lang.String mimeContentType) 
Allows sending a PRACK. 
void provisionalAckRsp(SipEndUser user, int connectionld, java.io.Serializable message, 
java.lang.String mimeContentType) 

Allows replying to an incoming PRACK. 
void registerReq(SipEndtlser user, SipRegistrationReq registration, java.io.Serializable body, 
java.lang.String bodytype) 

Allows registering the specified user at the given SIP Registrar, 
void reservationCoordReq(SipEndUser user, int connectionld, java.io.Serializable message, 
java.lang.String mimeContentType) 
Allows sending an UPDATE, 
void reservationCoordRsp(SipEndUser user, int connectionld, java.io.Serializable message, 
java.lang.String mimeContentType) 

Allows replying to an incoming UPDATE, 
static void setUserAgentFactory(SipUserAgentFactory fac) 

^^^^»ti^eg^ofa^^t^jg^factog^ 
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void conn^onCfmCSiplndUser user, int connertionld, java.lang.Stting from" 
java.,o Senal.zable body. java.lang.String mimeContentTyp^r 
Acknowledges a SIP session establishment, 
void prwisionalAckCfnKSipEndUser user, int connectionld, Java lana Strina from 

,aVa - , ° A '2l rial f ab,e b ° dv ' i^ 'ang-String mimeConteniTypS ' 
Acknowledges a PRACK. 

V °' d iavtlo , SriiK d K S H r U ? 6r ' fP^g^^Cfm registration, int status, 
java.io Serializable body, java.lang.String mimeContentType) 
-Aamqwledges a registration jgtniest 



JZico 



L-U-T—-— . f ».. 
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void connectionlniKSipEndUser user, int connectionld, java.lang. String from, j 
. java.io.Serializable body, java.lang. String mimeContentType) 1 
Indicates an incoming request of SIP session establishment j 

void provisionalAckInd(SipEndUser user, int connectionld, java.lang. String from, 

.' java.io.Serializable body, java.lang. String mimeContentType) j 

mn : ^ Indicates an incoming PRACKL _ > ^ . _ I 
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w«m Ind «^tes an incoming provisional response from the neer 
„ nH Acknowledges a former request to close the session. 

Indicates a request from the peer to close the session • 
Notifies the incoming of an OPTIONS 
Notifies the incoming of a MESSAGE VP 
u» M Acknowledges a former request to send an OPTIONS 
voM _ Acknowledges a a former request to send a MESSAGE 
voiH Acknowledges a former request to send an UPDATE 
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void bindReq(SIpEndUser user, SipRegistrarListener ssml) 

Binds the given user's event listener to the given SIP UA. 
void configureReq(SipManagementListener sml, SipConfigurationReq conf) 

Configures the given SIP UA. 
void optionsRsp(SipEndUser user, int connectionld, java.io.Serializable body, 
java.lang. String mirneContentType) 
Acknowledges an OPTIONS, 
void messageRsp( Sip End User user, int connectionld, java.io.Serializable body, 
java.lang. String mirneContentType) 
Acknowledges a MESSAGE, 
void registerRsp(SipEndUser user, int connectionld. Sip Registration Rsp registration, 
int status, java.io.Serializable body, java.lang. String bodytype) 

Primitive allowing a Registrar to reply to a request for registration from SIP users. 

■»••— ezisstus Bass taxsuttsssassasaBSss — BbaweaaesaeaassassJaiafeaa ssssAssszssuasssasts — aa ir .. ?> — 

Tab. 16 



VO ' d ^r?5 S . iPE K, dU K 8 i US . 8r ' , '" t ~ co " nect i°"«d;SipR7g»st;atlonlnd regi's^orT^l 
java.io.Serializable body, java.lang.String mimeContentType) 9 ,sw ™°"' j 

Indicates a request from the peer to make a registration. 

Ta^USS^^^' lr ? connectjonW ' Java.lang.String from, 
java.io Seriahzable body, java.lang.String mimeContentType) 

Notifies the incoming of an OPTIONS 

void messagelndfSipEndUser user, int connection^. java.lang.String from 

java.,o Serializable body. java.lang.String mimeContentType) 

Notifies the mcox n ing of a MESSAGR 
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Source State 


Triggering event 


Guard j 
condition 


Action 


Target 
state 


Root. Idle 


disconnectionCfm 




releaseCfm 


Root . % 
Idle 




releaseRsp 




di s connection 
Rsp 


Root. 
Idle 


Root . Wait RenewLeas e 
Rsp 


Timer T2 expires 




failurelnd 


Root. 
WaitTo i 
Clear j 


Root . WaitRenewLease 
Cfm 


connect ionS t a t u s Ind 


Status >= 
300 


abortlnd 


Root. 
Idle 




Timer T101 expires 




failurelnd 


Root . 

WaitTo 

Clear 


Root . WaitPreNegot 
Rsp 


Timer Tl expires 




failurelnd 


Root . 1 
Clear 


Root - WaitPreNegot 
Cfm 


connectionStatusInd 


Status >= 
300 


abortlnd 


Root • 




Timer T102 expires 




failurelnd 


Root . 

WaitTo 

Clear 


Root .NegOf f erer 


Timer T103 expires 




failurelnd 


Root. 

WaitToC 

lear 


Root . ReNegOf f erer . 
WaitNegReq 


connections tatus Xnd 


Status >= 
300 


abortlnd 


aOOu • 

Session 
Esta- 
blished 




Timer T5 expires 




_ResvMtx. sign 
al abortlnd 


Root • 
Idle 


Root . NegOf f erer . 
WaitTryinglnd 


connectionStatusInd 


Status >= 
300 


abortlnd 


Root • 
Idle 


Root . NegOf f erer . 
WaitProgressInd * 


connections tatus Ind 


Status >= 
300 " ' 


abortlnd 


Root. 
Idle 


Root . NegOf f erer . 
WaitNegS t a tus Rsp 


Timer T6 expires 




failurelnd 


Root . 

WaitTo 

Clear 


Root . NegOf f erer • 
WaitPrackCfm 


connectionStatusInd 


Status >= 
300 


failurelnd 


Root. 

WaitTo 

Clear 



SZco 



source State 


Triggering event 


Guard 
condition 


Action 


Target 
state 


Root . NegOf f erer . 
WaitReservCompl 


Timer T7 expires 




failurelnd 


Root. 

WaitTo 

Clear 


Root. NegOf f erer. 
WaitCoordCfm 


connectionStatusInd 


Status >== 
300 


failurelnd 


Root. 

WaitTo 

Clear 


Root . NegOf f erer . 
WaitRinging 


connectionStatusInd 


Status >— 
300 


failurelnd 


Root. 

WaitTo 

Clear 


Root . NegOf f erer . 
Wai t Fina 1 Pr o vAckC f m. 


connectionStatus Ind 


Status >=» 
300 


failurelnd 


Root. 

WaitTo 

Clear 


Root . NegOf f erer . 
WaitConnectionCfm 


connectionStatusInd 


Status >— 
300 


failurelnd 


Root. 

WaitTo 

Clear 


Root. NegOf f erer. 

WaitContract 

Adjusted 


Timer T8 expires 




failurelnd 


Root . 

WaitTo 

Clear 


Root . ReNegOf f erer 


Timer T104 expires 




failurelnd 


Root. * 
WaitTo 
Clear 


Root . ReNegOf f erer . 
WaitReNegReq 


connectionStatusInd 


Status >= 
300 


abortlnd 


Root. 
Session 
Esta- 
blished 




Timer T9 expires ~ — 




^ResvMtx. 

signal 

abortlnd 


Root. 
Idle 


Root . ReNegOf f erer . 
WaitTryinglnd 


connectionStatusInd 


Status >- 
300 


abortlnd 


Root. 
Session 
.Esta- 
blished 


Root • ReNegOf f erer - 
WaitProgressInd 


connectionStatusInd 


Status >= 
300 


abortlnd 


Root. 
; Session 
Esta- 


Root . ReNegOf f erer . 
WaitNegStatusRsp 


Timer T10 expires 




failurelnd 


Root. 

WaitTo 

Clear 





j Source State 


Triggering event 


Guard 
condition 


Action 


Target 
state j 


Root . ReNegOf f erer . 
1 WaitPrackCfm 


connect i r>n Status Tnd 


Status 
300 


a V*\ r\ v +~ T vs *A 


Root. ~ 
Session 
Est a- j 
blished 


Root. ReNegOf f erer. 
I WaitReservCon$>l 


Timer Til expires 




failurelnd 


Root . 

WaitTo 

Clear 


1 WaitCoordCfm 


connections tat us Ind 


Status >= 
300 


abortlnd 


Root. 
Session 
Esta- 
blished 


j Root. ReNegOf f erer. 
I Wait Ringing 


connect ionS tatu s Jnd 


Status >= 
300 


failurelnd 


Root. 

WaitTo 

Clear 


l Root • ReNegO f f erer • - 
WaitFinalProvAckCfni 


conne ctionS t a tu 3 2nd 


Status >= 
300 


abortlnd 


Root. 
Session 
Esta- 
blished 


I Root. ReNegOf f erer, 
I WaitConnectionCfm 


connectionStatusInd 


Status >= 
300 


abortlnd 


Root. 
Session 
Esta- 
blished 


j Root. ReNegOf f erer. 
j WaitContract 
Adjusted 


Timer T12 expires 




failurelnd ; 


Root. 

WaitTo 

Clear 




negotiationReq 




abortlnd 


Root. 
Neg 
Answe- 
rer 




reNegotxationRecg 




abortlnd 


Root. 
Neg 
Answe- 
rer 


1 


Timer T105 expires 




failurelnd 


Root. 

WaitTo 

Clear 


Root . NegAns wer er . 
WaitAnswer 


Timer T13 expires 




failurelnd 


Root . j 

WaitTo 

Clear 


Root . NegAns werer . 
WaitCounterOf fer 











Source state 


Triggering event 


Guard 
condition 


Action 


Target 
state 


Root . NegAns werer . 
WaitNegStatusRsp 


Timer T14 expires 




failurelnd 


Root, 

WaitTo 

Clear 


Root . NegAnswerer . 
WaitFinalProvAck 










Root . NegAnswerer . 
WaitFinalAnswer 


Timer T15 expires 




failurelnd 


Root. 

WaitTo 

Clear 


Root . NegAnswerer . 
HoldOnAnswer 










Root . NegAnswerer . 
WaitConnectionCfm 










Root . NegAnswerer - 
WaitForCoordDone . 
Wai tLocalCoord 


Timer T19 expires 




failurelnd 


Root, 

WaitTo 

Clear 


Root . NegAnswerer • 
WaitForCoordDone . 
WaitRemoteCoord 


Timer T20 expires 




failurelnd 

1 r 


Root. 

WaitTo 

Clear 


Root . NegAnswerer . 
WaitForCoordDone • 
LocalTokenAchieved 










Root . NegAnswerer - 
WaitForCoordDone . 
RemoteTokenAchieved 










Root . ReNegAnswerer 


Timer T106 expires 




failurelnd 


Root. 

WaitTo 

Clear 


Root . ReNegAnswerer . 
WaitAnswer 


Timer T16 expires 


■ 


failurelnd 


Root. 

WaitTo 

Clear 


Root . ReNegAnswerer . 
WaitCounterOf fer 










Root . ReNegAnswerer . 
WaitNegStatusRsp 


Timer T17 expires 




failurelnd 


Root. 

WaitTo 

Clear 


Root . ReNegAnswerer . 
Wai t Final P ro vAck 










Root . ReNegAnswerer • 
WaitFinalAnswer 


Timer T18 expires 




failurelnd 


Root. ~~" 

WaitTo 

Clear 
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Name 


Description 


Default 
Value 


Tl 


waiting pre-negotxation response from E2ENP UA API 
Service User 


TBD 


T2 


waiting lease renew response from E2ENP UA API 
Service User 


TBD 


T3 


Waiting release response from E2ENP UA API Service 
User 


TBD 


T4 


Waiting release request from E2ENP UA API Service 
User, after the E2ENP UA has generated a failure 
indication or a congestion indication to the 
Service User. 


TBD 


T5 


Waiting negotiation request from E2ENP UA API 
Service User after having booked the resource 
reservation mutex at the offerer side 


TBD 


T6 


Waiting negotiation status response with counter- 
offer, from E2ENP UA API service User at the 
offerer side 


fan 

J. ou 


T7 


Waiting start reservation response from E2ENP UA 
API Service User at the offerer side 




T8 


Waiting negotiation status response from E2ENP UA 
API Service User to handle contract adjustment at 
the offerer side 


TBD 


T9 


Waiting re-negotiation request from E2ENP UA API 
Service User after having booked the resource 
reservation mutex at the offerer side 


TBD 


T10 
"Til 


waiting re-negotiation status response with 
counter-offer, from E2ENP UA API Service User at 
the offerer side 


TBD 




Waiting start reservation response from E2ENP UA 
API Service User, during re-negotiation at the 
uiierer side 


TBD 


T12 


Waiting re-negotiation status response from E2ENP 
UA API Service User to handle contract adjustment 
at the offerer side 


TBD 



Name I Description 



SJoo 

Default: - 
Value 



T13 (Waiting negotiation status response with 



answer 



from E2ENP UA API Service User at the answerer 



side 



T14 j Waiting negotiation status response with 

counteroffer from E2ENP UA API Service User at the 



answerer side 



Waiting negotiation response from E2ENP UA" 
Service User at the answerer side 
waiting re-negotiation status response with" 
from E2ENP UA API Service User at the answerer 



API 



answer 



side 



T17 j Waiting re-negotiation status response with 

counteroffer from E2ENP UA API Service User at the 



answerer side 



T18 



T19 



Waiting re-negotiation response from E2ENP" 
Service User at the answerer side 
Waiting start reservation response from E2ENP 
!API Service User at the offerer 
negotiations 



UA API 



UA 



TBD 

TBD 

"TBD~ 
TBD 

TBD" 

TBD 
TBD 



side during 



E2ENP UA API 



T20 | Waiting negotiation response from 

Service User side for handling, adjusted contracts 
during negotiations 
tzi | Waiting start reservation response from E2ENP UA 

side during re- 



T22 



T101 



I API Service User at the offerer 
negotiations 

Waiting negotiation response from 

Service User side for handling adjusted contracts 
during re-negotiations 

waiting OPTIONS confirmation from SIP API for 



TBD 



TBD 



E2ENP UA API 



handling lease renewal primitive 
T102 | Waiting MESSAGE confirmation from SIP~ 
handling pre-negotiation primitive 



UA for 



TBD 



TBD 



TBD 



S9CO 



Name 


Description 


Default 
Value 


T103 


Exceeding delay in receiving any SIP UA Generic 
API primitive while acting as offerer in a 
negotiation process 


TBD ~ 


T104 


Exceeding delay in receiving any SIP UA Generic 
API primitive while acting as answerer in a 
negotiation process 


TBD 


T105 


Exceeding delay in receiving any SIP UA Generic 
API primitive while acting as offerer in a re- 
negotiation process 


TBD " 


T106 


Exceeding delay in receiving any SIP UA Generic 
API primitive while acting as answerer in a re- 
negotiation process 


TBD 
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